Re: [RDB DAS] Wrong Query Result when SELECT misses PKs
There is a bit of confusion around the RecursiveTests.testReadEngineParts() , in the context of this fix. Below is the data for tables, queries etc. sql return:- *1 Engine 1 - 2 Block 1 1 - - - - *1 Engine 1 - 3 Cam Soft 2 1 - - - - 1 Engine 1 -4 Piston 8 1 5 Piston Ring 2 4 table data:- id name qty parent id 1 Engine1 - 2 Block 1 1 3 Cam Soft2 1 4 Piston8 1 5 Piston Ring 2 4 query:- SELECT P1.ID, P1.NAME, P1.QUANTITY, P1.PARENT_ID, P2.ID, P2.NAME, P2.QUANTITY, P2.PARENT_ID, P3.ID, P3.NAME, P3.QUANTITY, P3.PARENT_ID FROM APP.PART AS P1 LEFT OUTER JOIN APP.PART AS P2 ON P1.ID = P2.PARENT_ID LEFT OUTER JOIN APP.PART AS P3 ON P2.ID = P3.PARENT_ID WHERE P1.ID = 1 See the recursiveTests. here the recursion occurs 3 times on the same (part) table and total 5 DOs should be formed in mem. (pre-existing case). Now see ResultSetProcessor.addRowToGraph(). if we take null data in pk as exception, the rows from sql return above marked with *, will cause the whole query to fail and so the recursiveTests will fail. But if we do some adjustments to allow this case to succeed, there can be other situations where not throwing exception for null data in PK for any row can cause problem (incomplete/wrong results). So, is it better to make RecursiveTests fail? Suggestions? Regards, Amita On 7/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: It seems ok Amita ; ) Adriano Crestani On 7/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, Yes, so in summary , trying to do following - 1) select missing complete or partial PK for any of the tables involved- exception 2) if any table in select has no PK in config and no ID column in config/select - exception 3) if any table in select has no PK in config and has ID column in config - exception 4) if any table in select has no PK in config but has ID column in SELECT - success Regards, Amita On 7/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: I had the same problem on DAS C++, now it's throwing an exception when it finds a row that does not contain all the pk columns. I'm not used to the DAS Java, but I will explain how I did it on DAS C++, maybe this can help you ; ) It reads the ResultSet metadata to find the pk columns. If the PK is defined on the config, so it look for the columns defined as pk on the config. In case it does not find the pk column(or columns if it is a compound pk), it looks for the ID columns according to DAS Convention Over Configuration rules. Otherwise it throws the exception. Does it help? : ) Regards, Adriano Crestani On 7/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Further on this, Need to consider single and compound PKs case. When select does not include complete PK (all PK columns from compound PK) , DAS needs to throw exception. As a fix proposing below changes:- AIn ResultMetadata - introduce new HashMap tableToPrimaryKeys , fill it during constuctor and provide get method - getAllPKsForTable(tableName). B In ResultSetRow - add method checkResultSetMissesPK(allTableNamesFromQueryResultSet) which will take each table and check if all PKs are there in result set. If not it will mark that TableData with hasValidPKs=FALSE. C There is already another check in TableData.addData(), which marks this flag FALSE, if any PK in result set has NULL data. B and C together will provide complete check DIn ResultSetRow, call, checkResultSetMissesPK(allTableNamesFromQueryResultSet) from processRow() and processRecursiveRow(). With this, all TableData will be set with proper hasValidPK, during ResultSetProcessor.processResultSet() and consequently, in ResultSetProcessor.addRowToGraph() will be able to do judgement if any table is missing PK, in which case DAS will throw RuntimeException and will not form DataGraph. Any comments/suggestions? Based on this I will work on patch for JIRA-1464. Regards, Amita On 7/19/07, haleh mahbod [EMAIL PROTECTED] wrote: It is best to throw an exception for PK not being there, otherwise an empty result set can have two meaning:Empty or something went wrong On 7/18/07, Adriano Crestani [EMAIL PROTECTED] wrote: Amita, There is now way for DAS to keep the relationship data consistence if both, pk and fk, are not completely defined. Without them DAS cannot predict the relationship. As Brent said, I think it could throw an exception when the
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[
https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517158
]
Amita Vadhavkar commented on TUSCANY-1464:
--
1 - On method ResultMetadata.getAllPKsForTable(String tableName), I understand
that you return an empty Set when there is no column in config, but why you add
an empty String on it?
Athere is a case when table does not have entry in cfg and is used in select.
also, there is no column
in select clause with name 'id' (ignore casesensitivity). so das logic can not
get a list of pks
for this table and treats all columns appearing in the select as pks. Check
ResultMetadata.isPKColumn()
(pre-existing method). Here when there are no columns in config, it returns
true. for this, in
ResultMetadata.getAllPKsForTable(String tableName), i am putting in the pk map
- table entry key with null
value against it.And so, getAllPKsForTable() will return null. After that , in
ResultSetRow.checkResultSetMissesPK(), when this null is detected, i set,
tableRShasPK to true. so this is
one classic case when all columns should be pks.
Bthere is another case when there is a table entry in cfg and has some columns
defed in it, but none is
set to pk, and also, there is no id column in cfg or in result set. in this
case, there is no entry
made in pk map. As there is no entry in map
ResultMetadata.getAllPKsForTable(String tableName)
will again return null, and there will be no way to distinguish this case from
the above classic case
(all cols are pks). so in order to distinguish, i am returning a hash with only
one entry . I have
a comment inline in getAllPKsForTable() where i am doing this. After that, in
checkResultSetMissesPK(),
when this condition is detected, set tableRShasPK to false.
so, basically das logic so far is such that, when possible give advantage of
doubt that the table
will have pk (A), but when user has explicitly defed columsn and table in cfg
and still has not
configed any column as pk, treat it differently(B) and if COC also is not able
to get a PK, treat
B as missing pk case and throw exception.
-
2 - On ResultSetProcessor, shouldn't be thrown an exception when the table has
pk but this pk is null instead of just ignoring the row?
sql return:-
*1 Engine 1 - 2 Block 1 1 - - - -
*1 Engine 1 - 3 Cam Soft 2 1 - - - -
1 Engine 1 -4 Piston8 1 5 Piston Ring 2 4
table data:-
id name qty parent id
1 Engine1 -
2 Block 1 1
3 Cam Soft 2 1
4 Piston8 1
5 Piston Ring 2 4
query:-
SELECT
P1.ID,
P1.NAME,
P1.QUANTITY,
P1.PARENT_ID,
P2.ID,
P2.NAME,
P2.QUANTITY,
P2.PARENT_ID,
P3.ID,
P3.NAME,
P3.QUANTITY,
P3.PARENT_ID
FROM
APP.PART AS P1 LEFT OUTER JOIN APP.PART AS P2
ON P1.ID = P2.PARENT_ID
LEFT OUTER JOIN APP.PART AS P3
ON P2.ID = P3.PARENT_ID
WHERE
P1.ID = 1
see the recursiveTests. here the recursion occurs 3 times on the same (part)
table and total 5 DOs
should be formed in mem. (pre-existing case).
now see ResultSetProcessor.addRowToGraph(). if we take null data in pk as
exception, the rows from
sql return above marked with *, will cause the whole query to fail. instead ,
if we go past the
exception (by not setting flag to false for null pk), we can ensure ahead that
DOs will null
PK do not enter registry.
the below check in ResutlSetProcessor.addRowToGraph() does this.
if (tableObject == null
!rawDataFromRow.getPrimaryKeyValues().contains(null)) {//2nd check for null
data in PK,
with this check, in the recursive test case as well as other cases when the pk
is null value, DO will
not form and will not enter table registry and so in tableObjects(RowObject)
collection. Also, as it
is not in tableObjects, no relationship will be processed on it (so child table
rows will not come in).
But, even I concur with you, that to keep things clean, we can make
RecursiveTests fail and clear cut
throw exception for any occurence of null data in PK. Any idea about the
reason for the RecursiveTests?
I am sending a mail to ML, lets see the replies(you also give your view there
please) and based on that
I will correct this portion of code.
--
3- Sorry, but I didn't get why you added the ID attribute on company.xsd : (
this xsd is used in companytests. so far, as we were allowing missing pks in
select, this was
working without failure. but with 1464, the selects had to be changed to add PK
columns. Now with
this change, the xsd and selects had mismatch, because id was missing in xsd
and
[jira] Commented: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517162 ] Adriano Crestani commented on TUSCANY-1464: --- 1- OK 2 - commented on ML 3- As ID column being considered primary key is a Convention Over Configuration issue, I think the user shouldn't need to declare it anywhere, cause DAS should recognize it anyway. What do you think? Regards, Adriano Crestani Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 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: 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- 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: [RDB DAS] Wrong Query Result when SELECT misses PKs
Yes, I think it should fail, once DAS shouldn't omit a data from the user. Cause, if the pk has null pk, it means it doesn't have an id and cannot be guaranteed its uniqueness. I think maybe DAS should not throw the exception, but needs to warn the user when any row is omitted, however I don't think it is a good approach at all. My suggestion is that it should fail whenever is found a null pk. Regards, Adriano Crestani On 8/2/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: There is a bit of confusion around the RecursiveTests.testReadEngineParts () , in the context of this fix. Below is the data for tables, queries etc. sql return:- *1 Engine 1 - 2 Block 1 1 - - - - *1 Engine 1 - 3 Cam Soft 2 1 - - - - 1 Engine 1 -4 Piston 8 1 5 Piston Ring 2 4 table data:- id name qty parent id 1 Engine1 - 2 Block 1 1 3 Cam Soft2 1 4 Piston8 1 5 Piston Ring 2 4 query:- SELECT P1.ID, P1.NAME, P1.QUANTITY, P1.PARENT_ID, P2.ID, P2.NAME, P2.QUANTITY, P2.PARENT_ID, P3.ID, P3.NAME, P3.QUANTITY, P3.PARENT_ID FROM APP.PART AS P1 LEFT OUTER JOIN APP.PART AS P2 ON P1.ID = P2.PARENT_ID LEFT OUTER JOIN APP.PART AS P3 ON P2.ID = P3.PARENT_ID WHERE P1.ID = 1 See the recursiveTests. here the recursion occurs 3 times on the same (part) table and total 5 DOs should be formed in mem. (pre-existing case). Now see ResultSetProcessor.addRowToGraph(). if we take null data in pk as exception, the rows from sql return above marked with *, will cause the whole query to fail and so the recursiveTests will fail. But if we do some adjustments to allow this case to succeed, there can be other situations where not throwing exception for null data in PK for any row can cause problem (incomplete/wrong results). So, is it better to make RecursiveTests fail? Suggestions? Regards, Amita On 7/28/07, Adriano Crestani [EMAIL PROTECTED] wrote: It seems ok Amita ; ) Adriano Crestani On 7/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Adriano, Yes, so in summary , trying to do following - 1) select missing complete or partial PK for any of the tables involved- exception 2) if any table in select has no PK in config and no ID column in config/select - exception 3) if any table in select has no PK in config and has ID column in config - exception 4) if any table in select has no PK in config but has ID column in SELECT - success Regards, Amita On 7/27/07, Adriano Crestani [EMAIL PROTECTED] wrote: I had the same problem on DAS C++, now it's throwing an exception when it finds a row that does not contain all the pk columns. I'm not used to the DAS Java, but I will explain how I did it on DAS C++, maybe this can help you ; ) It reads the ResultSet metadata to find the pk columns. If the PK is defined on the config, so it look for the columns defined as pk on the config. In case it does not find the pk column(or columns if it is a compound pk), it looks for the ID columns according to DAS Convention Over Configuration rules. Otherwise it throws the exception. Does it help? : ) Regards, Adriano Crestani On 7/27/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Further on this, Need to consider single and compound PKs case. When select does not include complete PK (all PK columns from compound PK) , DAS needs to throw exception. As a fix proposing below changes:- AIn ResultMetadata - introduce new HashMap tableToPrimaryKeys , fill it during constuctor and provide get method - getAllPKsForTable(tableName). B In ResultSetRow - add method checkResultSetMissesPK(allTableNamesFromQueryResultSet) which will take each table and check if all PKs are there in result set. If not it will mark that TableData with hasValidPKs=FALSE. C There is already another check in TableData.addData(), which marks this flag FALSE, if any PK in result set has NULL data. B and C together will provide complete check DIn ResultSetRow, call, checkResultSetMissesPK(allTableNamesFromQueryResultSet) from processRow() and processRecursiveRow(). With this, all TableData will be set with proper hasValidPK, during ResultSetProcessor.processResultSet() and consequently, in ResultSetProcessor.addRowToGraph() will be able to do judgement if any table is missing PK, in which case DAS will throw RuntimeException and will not form DataGraph. Any comments/suggestions? Based on this I will
Re: [RDB DAS] Consistent use of Parameters in Config
JPQL, Hibernate ,... have support for named parameters. Why is RDB DAS going in the other way? If there is a reason for switching off named parameters, please elaborate, else is it OK to go for JIRA-1462? Regards, Amita On 7/13/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: I went through [1] and [2], it talks about removing name attribute from Parameter and about generatedKeys. Also saw JIRA-528 on the way. But I could not get the exact rational behind removing Name from Parameter (It is definitely not required by JDBC for sure, but can have some aid in usage clarity) 1)One place in RDB DAS (here Name is not removed and can not be removed) BasicCustomerMappingWithCUD.xml (CRUDWithChangeHistory.testDeleteAndCreate ()) Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd; Table tableName=CUSTOMER create sql=insert into customer values (?, ?, ?) parameters=ID LASTNAME ADDRESS/ update sql=update customer set lastname = ?, address = ? where ID = ? parameters=LASTNAME ADDRESS ID/ delete sql=delete from customer where ID = ? parameters=ID/ /Table /Config This is informative because we have create sql=insert into customer values (?, ?, ?) parameters=ID LASTNAME ADDRESS/ In the client code we will typically have DataObject customer = root.createDataObject(CUSTOMER); customer.setInt(ID, 720); customer.set(LASTNAME, foobar); customer.set(ADDRESS, asdfasdf); das.applyChanges(root); Here client has a chance to understand that he needs to set ID, LASTNAME, ADDRESS because the config states - parameters=ID LASTNAME ADDRESS and internally we will map names to idx when doing PreparedStatement.setParameter. For the matter of whether it is required to have parameters=ID LASTNAME ADDRESS , it is required. We can no say parameters=1 2 3 or X Y Z because during SDO to Parameter mapping (in ChangeOperation) we need the Name of parameter, so Name and Idx both are required. 2)Another place in RDB DAS (this is where Name is removed in JIRA-658) Command name=InsertCustomers SQL=insert into CUSTOMER values (?,?,?) kind=Insert Parameter direction=IN index=1 columnType=commonj.sdo.IntObject / Parameter direction=IN index=2 columnType=commonj.sdo.String/ Parameter direction=IN index=3 columnType=commonj.sdo.String/ /Command A typical client code will be, Command insert = das.getCommand(InsertCustomers); insert.setParameter(1, 1000); insert.setParameter(2, MYNAME); insert.setParameter(3, MYADDR); insert.execute(); In this example, nowhere the client has a way to know what 1000, MYNAME or MYADDRESS means. If this is a table with many columns and such many tables, how the client is going to set values using setParameter() with any comfort level, unless otherwise the he has a direct access to database and can know the names and order or columns in database table or if the insert syntax is used like insert into CUSTOMER (ID, LASTNAME, ADDRESS) values (?,?,?) but in tables having large number of rows, it is likely that client will try to have short (insert) statements without column names. And this is what I felt was the issue of the user in http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html, as he admitted that even though JDBC does not need Names, he needs it for the sake of clarity. So, as such, first thig I am just curious to know is, what were the advantages of JIRA-658? Also, not quite clear about Also, have you thought about multiple queries retrieving the same column,you would have to configure the parameter in multiple places. If there are 10 different Select Commands with 10 different Where clauses, we anyway need to set Parameters in 10 different places. I guess I am completely intepreting something wrong here, please help. Regards, Amita On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: The named parameter support was removed from earlier versions of DAS, here is some previous discussion around the subject [1] See also tuscany-658. We might need to do further cleanup on the impl, if I understood correctly. As for your second suggestion (parameter column types), could you expose some use cases scenarios where this would be helpful ? Also, have you thought about multiple queries retrieving the same column, you would have to configure the parameter in multiple places. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg04672.html [2] http://issues.apache.org/jira/browse/TUSCANY-658 On 7/12/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, A few days ago there was a user question about passing name in Parameter:- http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19339.html When checking how Parameters are used in Config, came across the following points. There is a difference in Config (SDO) generated
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517178 ] Andy Grove commented on TUSCANY-1397: - We discussed this issue in last week's SDO spec. call and decided that for now (SDO 2.1.1) we will leave this behaviour unspecified but there seemed to be general concensus that the correct behaviour (to be clarified for SDO 3.0) would be to on-demand create the property for consistency with other set() methods. createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build failure in binding-ejb
The latest Java SCA trunk doesn't build from a clean checkout because of a failure building binding-ejb (a NoClassDefFoundError for org/objectweb/asm/Type). This was puzzling because there are no recent changes to binding-ejb. With a vital clue from Ant, I traced the problem to the recent change that was made to the pom for implementation-java-runtime as part of the patch for TUSCANY-1492. If the recently added dependency in this file is changed from dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.1_3/version /dependency to dependency groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version /dependency then the build runs OK. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1397
I may commit it till the eod if nobody has no objection ; ) Adriano Crestani On 8/2/07, Andy Grove [EMAIL PROTECTED] wrote: I've submitted a patch for TUSCANY-1397 and I'd like someone to review this before I apply it since it is my first patch to the Tuscany SDO implementation (I've only been submitting to the CTS until now). The purpose of this patch is to implement on-demand creation of properties in createDataObject(). https://issues.apache.org/jira/browse/TUSCANY-1397 Thanks, Andy.
[jira] Created: (TUSCANY-1504) getSequence() returns null with a complexType defined without mixed=true
getSequence() returns null with a complexType defined without mixed=true -- Key: TUSCANY-1504 URL: https://issues.apache.org/jira/browse/TUSCANY-1504 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Reporter: Matthew Schultz getSequence returns null if complextType does not have the mixed attribute or the mixed attribute is set to false. Looking at the code, SDOSchemaSAX2Parser::startComplexType and SDOSchemaSAX2Parser::defineType appears to be the two places that isSequenced is set. In startComplexType, it appears that both mixed and sequence are both treated as an attribute. I cannot tell if it ever reads the child sequence. It appears that isSequenced should be set to true on the basis of the child sequence and not on the basis of mixed. -- 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-1504) getSequence() returns null with a complexType defined without mixed=true
[ https://issues.apache.org/jira/browse/TUSCANY-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517286 ] Matthew Schultz edited comment on TUSCANY-1504 at 8/2/07 8:07 AM: -- Here's an example xsd. If you try to run getSequence on the root data object, getSequence returns null. If you add mixed=true to complexType, getSequence returns an object. was: Here's an example xsd. If you try to run getSequence on the root data object, getSequence returns null. If you add mixed=true to complextType, getSequence returns an object. getSequence() returns null with a complexType defined without mixed=true -- Key: TUSCANY-1504 URL: https://issues.apache.org/jira/browse/TUSCANY-1504 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Reporter: Matthew Schultz Attachments: letter.xsd getSequence returns null if complextType does not have the mixed attribute or the mixed attribute is set to false. Looking at the code, SDOSchemaSAX2Parser::startComplexType and SDOSchemaSAX2Parser::defineType appears to be the two places that isSequenced is set. In startComplexType, it appears that both mixed and sequence are both treated as an attribute. I cannot tell if it ever reads the child sequence. It appears that isSequenced should be set to true on the basis of the child sequence and not on the basis of mixed. -- 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-1504) getSequence() returns null with a complexType defined without mixed=true
[ https://issues.apache.org/jira/browse/TUSCANY-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Schultz updated TUSCANY-1504: - Attachment: letter.xsd Here's an example xsd. If you try to run getSequence on the root data object, getSequence returns null. If you add mixed=true to complextType, getSequence returns an object. getSequence() returns null with a complexType defined without mixed=true -- Key: TUSCANY-1504 URL: https://issues.apache.org/jira/browse/TUSCANY-1504 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-M3 Reporter: Matthew Schultz Attachments: letter.xsd getSequence returns null if complextType does not have the mixed attribute or the mixed attribute is set to false. Looking at the code, SDOSchemaSAX2Parser::startComplexType and SDOSchemaSAX2Parser::defineType appears to be the two places that isSequenced is set. In startComplexType, it appears that both mixed and sequence are both treated as an attribute. I cannot tell if it ever reads the child sequence. It appears that isSequenced should be set to true on the basis of the child sequence and not on the basis of mixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
I have reopened the JIRA and will give it a try... On 8/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[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]
[jira] Reopened: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
[ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reopened TUSCANY-1053: -- Assignee: Luciano Resende (was: ant elder) Reopening per latest discussion comments : ...this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: Luciano Resende Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: (was: sca_itest_echoService.jar) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Golick updated TUSCANY-1347: - Attachment: sca_itest_echoService.jar The attached version of the test case code has been modified as suggested by Jean-Sebastien's comment. This version now fails with a NPE in RuntimeSCABindingInvoker with this stack trace: test_asyncEchoService(org.apache.tuscany.sca.test.echoService.EchoServiceTestCase) Time elapsed: 0.07 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy4.echoResults(Unknown Source) at org.apache.tuscany.sca.test.echoService.AsyncEchoServiceImpl.echo(AsyncEchoServiceImpl.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy3.echo(Unknown Source) at org.apache.tuscany.sca.test.echoService.EchoServiceImpl.asyncEcho(EchoServiceImpl.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy2.asyncEcho(Unknown Source) at org.apache.tuscany.sca.test.echoService.RelayServiceImpl.asyncEcho(RelayServiceImpl.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.runtime.RuntimeSCABindingInvoker.invoke(RuntimeSCABindingInvoker.java:41) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:143) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:73) at $Proxy2.asyncEcho(Unknown Source) at org.apache.tuscany.sca.test.echoService.EchoServiceTestCase.test_asyncEchoService(EchoServiceTestCase.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at
[jira] Resolved: (TUSCANY-1492) Support implemental class not only interface when get a service
[ https://issues.apache.org/jira/browse/TUSCANY-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1492. --- Resolution: Fixed Patch applied. Thank you so much. Support implemental class not only interface when get a service --- Key: TUSCANY-1492 URL: https://issues.apache.org/jira/browse/TUSCANY-1492 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.91 Environment: JDK1.5.09,winXP Reporter: wangfeng Priority: Minor Fix For: Java-SCA-0.91 Attachments: patch.txt, TestCase_Calculator.zip when we get a service,we always generate a proxy on the service by using the jdk proxy class, so we must provide a interface to get a service. I provide a patch to remove the control. This patch not only support the interface,but also support the implemental class when getting a service.when the class isn't a interface,using the cglib to generate a proxy and using jdk proxy when the class is a interface. -- 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: Build failure in binding-ejb
Hi, Simon. It's strange. I ran a full build and it didn't hit the problem? I aslo didn't see a failure report from continuum. It seems to be a bit random. BTW, what's the difference between cglib.jar and cglib-nodep.jar? If cglib-nodep helps, I'm happy to fix it. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 02, 2007 4:41 AM Subject: Build failure in binding-ejb The latest Java SCA trunk doesn't build from a clean checkout because of a failure building binding-ejb (a NoClassDefFoundError for org/objectweb/asm/Type). This was puzzling because there are no recent changes to binding-ejb. With a vital clue from Ant, I traced the problem to the recent change that was made to the pom for implementation-java-runtime as part of the patch for TUSCANY-1492. If the recently added dependency in this file is changed from dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.1_3/version /dependency to dependency groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version /dependency then the build runs OK. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reference EJB Binding problem
Hi, I have modified the Calculator sample to use an EJB binding for addService. I have deployed an AddService bean in Geronimo 2.0-SNAPSHOT Tomcat server. I am using an EmbeddedSCADomain to run the sample. I am facing a strange problem. When I run the sample in J2SE environment (I actually modified the testcase in sca/modules/binding-ejb to run this sample) everything runs fine. I see that the EJB is invoked for AddService. But when I run this sample inside Geronimo using the tuscany-plugin (see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationfor details on the Geronimo Tuscany Integration details), I am getting java.rmi.MarshalException: Unable to create stub for class java.lang.Object; nested exception is: org.omg.CORBA.MARSHAL: Unable to create stub for class java.lang.Object: vmcid: Apache minor code: 0x2e completed: No Here is the reference ejb binding xml-fragment from Calculator-new.composite reference name=addService interface.java interface=calculator.AddService/ binding.ejb uri=corbaname:iiop:[EMAIL PROTECTED] :1050#AddServiceBean/ /reference Here is the session bean definition in ejb-jar.xml: session descriptionAddService Bean/description display-nameAddServiceBean/display-name ejb-nameAddServiceBean/ejb-name homecalculator.AddServiceHome/home remotecalculator.AddService/remote local-homecalculator.AddServiceLocalHome/local-home localcalculator.AddServiceLocal/local ejb-classcalculator.AddServiceBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session And the binding in openejb-jar.xml: session ejb-nameAddServiceBean/ejb-name jndi-nameAddServiceBean/jndi-name ... /session Any ideas on what is making the difference in J2SE and J2EE enviroments in this context? Any help in resolving this problem is appreciated. Thanks and best regards, Vamsi
Re: Java SDO failing on tests
JDK version: java version 1.6.0_02 Java(TM) SE Runtime Environment (build 1.6.0_02-b06) Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing) maven version: 2.0.7 and probably the latest sdo code, downloaded 4 hours ago from /tuscany/java/sdo/ Regards, Adriano Crestani On 8/2/07, ant elder [EMAIL PROTECTED] wrote: On 8/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I've downloaded the SDO from the trunk today and got the following errors when running 'mvn' on /tuscany/sdo/ dir: Results : Tests in error: testConversionsFromDate( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromDateTime( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromDuration( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromMonth( org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonthDay( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromYear( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromYearMonth( org.apache.tuscany.sdo.test.DateConversionTestCas e) testConversionsFromYearMonthDay( org.apache.tuscany.sdo.test.DateConversionTest Case) Tests run: 189, Failures: 0, Errors: 8, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 6 minutes 42 seconds [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007 [INFO] Final Memory: 10M/34M [INFO] Anyone else getting these errors too? Adriano Crestani Its building fine for me. As those failures all seem to be date/time related i wondered if it was a JDK thing, but i've just tried with several JDK's and it always works fine. Also building with an empty local mvn repository is working ok for me, so i'm not sure what the problem could be. Are you definitely on the latest code, and what JDK and mvn version are you using? ...ant
Re: Build failure in binding-ejb
cglib-nodep is a jar containing all the dependencies of cglib, including asm. cglib is a jar that does not include these dependencies. In all the other places in Tuscany where cglib is used, the dependency is always on cglib-nodep, not on cglib. Simon Raymond Feng wrote: Hi, Simon. It's strange. I ran a full build and it didn't hit the problem? I aslo didn't see a failure report from continuum. It seems to be a bit random. BTW, what's the difference between cglib.jar and cglib-nodep.jar? If cglib-nodep helps, I'm happy to fix it. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 02, 2007 4:41 AM Subject: Build failure in binding-ejb The latest Java SCA trunk doesn't build from a clean checkout because of a failure building binding-ejb (a NoClassDefFoundError for org/objectweb/asm/Type). This was puzzling because there are no recent changes to binding-ejb. With a vital clue from Ant, I traced the problem to the recent change that was made to the pom for implementation-java-runtime as part of the patch for TUSCANY-1492. If the recently added dependency in this file is changed from dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.1_3/version /dependency to dependency groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version /dependency then the build runs OK. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1397
I think the patch is based on an older version of DataObjectUtil.java. Can you create a new patch? Thanks. Adriano Crestani [EMAIL PROTECTED] wrote: I may commit it till the eod if nobody has no objection ; ) Adriano Crestani On 8/2/07, Andy Grove wrote: I've submitted a patch for TUSCANY-1397 and I'd like someone to review this before I apply it since it is my first patch to the Tuscany SDO implementation (I've only been submitting to the CTS until now). The purpose of this patch is to implement on-demand creation of properties in createDataObject(). https://issues.apache.org/jira/browse/TUSCANY-1397 Thanks, Andy.
[jira] Updated: (TUSCANY-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances
[ https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1505: Attachment: test1505.zip Attached is a zip with test materials that will reproduce the problem described. Naming scheme used for variables in code gen factory init() method breaks under specific circumstances -- Key: TUSCANY-1505 URL: https://issues.apache.org/jira/browse/TUSCANY-1505 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Priority: Minor Fix For: Java-SDO-Next Attachments: test1505.zip A new code gen pattern was recently added to change how dependent packages are initialized in the xxxFactoryImpl.init() method. Under this new pattern, all dependent packages are initialized via the factoryInterface.INSTANCE method. An initialization call is made for each dependent gen package. The getImportedFactoryInterfaceName() is used to retrieve the short name. This value is mashed with the text 'Instnace' to form a variable name. If circumstances dictate that multiple packages contain the same factory interface name, the getImportedFactoryInterfaceName() will fully qualify the response instead of using the short name. This breaks the generated code, due to the use of a '.' in the variable name. -- 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: Reference EJB Binding problem
I suspect a something somewhere is using the wrong class loader, but its hard to tell precisely where without being able to debug by stepping through the code. Any chance you could make your code available somewhere (a zip file in a jira or anywhere?) so we can try it? ...ant On 8/2/07, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I have modified the Calculator sample to use an EJB binding for addService. I have deployed an AddService bean in Geronimo 2.0-SNAPSHOT Tomcat server. I am using an EmbeddedSCADomain to run the sample. I am facing a strange problem. When I run the sample in J2SE environment (I actually modified the testcase in sca/modules/binding-ejb to run this sample) everything runs fine. I see that the EJB is invoked for AddService. But when I run this sample inside Geronimo using the tuscany-plugin (see http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Geronimo+Integrationfor details on the Geronimo Tuscany Integration details), I am getting java.rmi.MarshalException: Unable to create stub for class java.lang.Object; nested exception is: org.omg.CORBA.MARSHAL: Unable to create stub for class java.lang.Object: vmcid: Apache minor code: 0x2e completed: No Here is the reference ejb binding xml-fragment from Calculator-new.composite reference name=addService interface.java interface=calculator.AddService/ binding.ejb uri=corbaname:iiop:[EMAIL PROTECTED] :1050#AddServiceBean/ /reference Here is the session bean definition in ejb-jar.xml: session descriptionAddService Bean/description display-nameAddServiceBean/display-name ejb-nameAddServiceBean/ejb-name homecalculator.AddServiceHome/home remotecalculator.AddService/remote local-homecalculator.AddServiceLocalHome/local-home localcalculator.AddServiceLocal/local ejb-classcalculator.AddServiceBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type /session And the binding in openejb-jar.xml: session ejb-nameAddServiceBean/ejb-name jndi-nameAddServiceBean/jndi-name ... /session Any ideas on what is making the difference in J2SE and J2EE enviroments in this context? Any help in resolving this problem is appreciated. Thanks and best regards, Vamsi
0.91 Memory Footprint
We recently migrated our version of Tuscany from M2 to 0.91, and we noticed that the memory consumption seems to have increased by quite a bit. When doing memory profiling, the culprit appeared to be classes related to Xerces DOM (DeferredElementNSImpl, several other schema element related classes). When profiling the samples (helloworld-ws-sdo-webapp) and our application in M2, those classes don't seem to get called. We are going through the jars to determine which module is triggering the Xerces parser, but any suggestions would be greatly appreciated.
Re: [VOTE] Release Tuscany Java DAS beta1 (RC3)
I ran the ComanyWeb and Ajax samples on OS X/Tomcat 6 and both ran fine. I think the Ajax example could be changed a bit to be more intuitive. For example, it is not clear what is happening with the OCC example. The Adhoc query example looks good but the Converter exercise is confusing; mainly because it is a direct exposure of a test case that was a bit contrived. Another possible simplification would be to have the two samples share the same database. This would save the user a bit of required configuration. Nice job on the release. +1 On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote: Please vote to release the beta1 distribution of Tuscany DAS for Java. All the major issues reported in RC1 and RC2 should now be fixed. The Release Candidate RC3 for Tuscany Java DAS beta1 is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/ Release Notes are available at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/distribution/binary/RELEASE_NOTES The maven repository artifacts are posted in a staging repository and is available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/maven/ The release audit tool (rat) results are available at http://people.apache.org/~lresende/tuscany/das-beta1-rc3/das-beta1-rc3-rat.log The tag for the source code is at https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1-rc3/ Seems OK to me, here is my +1 -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1492) Support implemental class not only interface when get a service
[ https://issues.apache.org/jira/browse/TUSCANY-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517421 ] wangfeng commented on TUSCANY-1492: --- Thank Raymond for applying the patch. Support implemental class not only interface when get a service --- Key: TUSCANY-1492 URL: https://issues.apache.org/jira/browse/TUSCANY-1492 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.91 Environment: JDK1.5.09,winXP Reporter: wangfeng Priority: Minor Fix For: Java-SCA-0.91 Attachments: patch.txt, TestCase_Calculator.zip when we get a service,we always generate a proxy on the service by using the jdk proxy class, so we must provide a interface to get a service. I provide a patch to remove the control. This patch not only support the interface,but also support the implemental class when getting a service.when the class isn't a interface,using the cglib to generate a proxy and using jdk proxy when the class is a interface. -- 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: Java SDO failing on tests
java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) the same result, failing on the same tests :( Adriano Crestani On 8/2/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Adriano Just a thought, could you try and see if it would work with JDK 1.5x. On 8/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: JDK version: java version 1.6.0_02 Java(TM) SE Runtime Environment (build 1.6.0_02-b06) Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing) maven version: 2.0.7 and probably the latest sdo code, downloaded 4 hours ago from /tuscany/java/sdo/ Regards, Adriano Crestani On 8/2/07, ant elder [EMAIL PROTECTED] wrote: On 8/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: Hi, I've downloaded the SDO from the trunk today and got the following errors when running 'mvn' on /tuscany/sdo/ dir: Results : Tests in error: testConversionsFromDate( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromDateTime( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromDuration( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromMonth( org.apache.tuscany.sdo.test.DateConversionTestCase) testConversionsFromMonthDay( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromYear( org.apache.tuscany.sdo.test.DateConversionTestCase ) testConversionsFromYearMonth( org.apache.tuscany.sdo.test.DateConversionTestCas e) testConversionsFromYearMonthDay( org.apache.tuscany.sdo.test.DateConversionTest Case) Tests run: 189, Failures: 0, Errors: 8, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 6 minutes 42 seconds [INFO] Finished at: Thu Aug 02 10:24:50 GMT-04:00 2007 [INFO] Final Memory: 10M/34M [INFO] Anyone else getting these errors too? Adriano Crestani Its building fine for me. As those failures all seem to be date/time related i wondered if it was a JDK thing, but i've just tried with several JDK's and it always works fine. Also building with an empty local mvn repository is working ok for me, so i'm not sure what the problem could be. Are you definitely on the latest code, and what JDK and mvn version are you using? ...ant -- 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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
This is a real pity IMHO as it makes the SCDL significantly more complicated, ugly and error prone, changing this namespace is going to do nothing to help usability. I know line 2535 in the spec is clear, but the actual SCA schema supports doing this doesn't it? Could we just ignore line 2535, or propose all the extensions we have as spec proposals, or something, anything else to avoid this PITA? At the very least we'll need to hightlight a change like this very clearly in the release notes and website doc on all the extensions, and ensure there's a really explicit and helpful error message produced when you get the namespace wrong. ...ant On 8/2/07, Luciano Resende [EMAIL PROTECTED] wrote: I have reopened the JIRA and will give it a try... On 8/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[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: Patch for TUSCANY-1397
I've patched the sdo trunk under revision 562325 with the patch Andy created. All tests ran fine, even though it failed on the tests described on thread [1], but I these fails have nothing to do with Andy patch, so it's ok for me ; ). Anyway, I will wait for a new created patch from Andy, once Fuhwei is saying the actual patch is based on an older version. [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/browser Regards, Adriano Crestani On 8/2/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: I think the patch is based on an older version of DataObjectUtil.java. Can you create a new patch? Thanks. Adriano Crestani [EMAIL PROTECTED] wrote: I may commit it till the eod if nobody has no objection ; ) Adriano Crestani On 8/2/07, Andy Grove wrote: I've submitted a patch for TUSCANY-1397 and I'd like someone to review this before I apply it since it is my first patch to the Tuscany SDO implementation (I've only been submitting to the CTS until now). The purpose of this patch is to implement on-demand creation of properties in createDataObject(). https://issues.apache.org/jira/browse/TUSCANY-1397 Thanks, Andy.
