[jira] Updated: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
[ https://issues.apache.org/jira/browse/TUSCANY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-961: Attachment: 961.patch List of files changed: *1) DAS -set/get for helperContext *2)DasFactory -2 new createDAS() methods accepting helperContext from caller *3)GraphBuilderMetaData -new constructor accepting helperContext -new SDO methods - createType(), getType(), createProperty(), getProperty(), getTypes() -using helperContext param improved logic to avoid recreation of existing Types and Properties improved logic to avoid numerous TypeHelper creation (old DAS has 1 instance/1 read command) *4)GraphMerger -new member vars HelperContext and TypeHelper -new constructor accepting helperContext from caller -emptyGraph() - uses new SDO methods - createType(), getType(), createProperty(), getProperty(), getTypes() using helperContext param *5)DasFactoryImpl -impls of 1) *6)DasImpl -new member HelperContext, set/get -DASImpls for 4) -get/createCommand with setHelperContext() calls. *7)BaseCommandImpl -new member helperContext (holds ref from DASImpl), setter/getter -This approach is followed, so that without DAS, caller can directly set helperContext in command. -This way in a scenario, where say there are multiple database schemas involved in a business case and user wants to keep different contexts in SDO/dbms schema, he can make sure to pass different context to different commands, based on the dbms schemas involved..and so forth. *8)ReadCommandImpl -new SDOUtil.createDataGraph() -new GraphBuilderMetadata() passing helperContext from command *9)UpdateGenerator -getUpdateCommand() - used new dataObject.getInstanceProperty() *10)CompanyTests -testSimpleStatic() - CompanyFactory registered in context 11)ConverterTests -CustomerFactory register *12)ExceptionTests -CustomerFactory, CompanyFactory register *13)GraphMergeTests -diff Type Factory register *14)TopDown -diff Type Factory register *15)SimplestStaticCrud -testRead() - new way to register context in CustomerFactory *16)AliaseTests -added new CustomerData() in setUp() already in JIRA 1464 (under review) *17)ReadCustomersStaticTypesCommand -CustomerFactory registered in context in new way *18)ReadCustomersStaticTypesCommand2 - new test case for passing -HelperContext from caller *19)GeneratedCommandTests. -testReadCustomersStaticTypes2() for 19) *20) new Unit Tests - HelperContextTests *21) DasTest - superclass of all test cases - in setUp() calls -HelperProvider.getInstance(); This is required so that each test case gets a clean HelperContext. Otherwise, places where column converters are used e.g. there will be a conflict in Type of a column (e.g. Customer.ID is int, but in converter test it is long.) If SDO JIRA-761 is resolved, this approach can be changed and in DasTest.setUp(), we can do unregister of required namespaces instead of creating new instances of HelperProvider. *22) AllCommonTests - -include HelperContextTests *23) sample-ajax-das -DasQueryProcessor.getRSS() , getConverter()- HelperProvider.getInstance() added as converters need a clean helper context. DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: https://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 961.patch The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- 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: [DAS] DAS SDO
Please check patch for JIRA-961. A,B,C is the approach followed. Regards, Amita On 8/1/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: ASo far, RDB DAS was doing SDOUtil.createTypeHelper() during each construction of GraphBuilderMetadata(GBMD). This was resulting in a new instance fo TypeHelper for each new query execution. This is not required as the data model used during one runtime of DAS is constant. BUsing the new SDO APIs, we can do HelperProvider.getDefaultContext ().getTypeHelper() in this case to consistently use the same TypeHelper instance. CAnother question is, when a user extends ReadCommandImpl and also provide a static data model - like in - ReadCustomersStaticTypesCommand from test suite, and also uses a HelperContext different than DefaultContext to register the static Types, (please see, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20743.html), then how to make DAS and thus GraphBuiilderMetaData aware of this new HelperContext. One simple solution will be providing a way through DASImpl to pass the helperContext to GraphBuilderMetaData, when it is not the DefaultContext. BaseCommandImpl, can hold ref to HelperContext instance and pass it to GBMD. GBMD will use passed HelperContext and in its absense will use the default one. D Alternative to C will be mandating user to use DefaultHelperContext? Please give comments. Regards, Amita On 7/20/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have started checking the details and will consolidate my findings here. Regards, Amita On 7/20/07, Luciano Resende [EMAIL PROTECTED] wrote: Hey Kelvin gave as some head's up of upcoming changes that might affect DAS [1] and [2] (Thanks Kelvin). I think there is also a JIRA regarding integration with latest SDO 2.1 APIs [2] and the usage of deprecated SDO APIs [4]. It would be great if someone could help on getting these issues and JIRAs reviewed, and submit patches as needed. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20388.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20369.html [3] http://issues.apache.org/jira/browse/TUSCANY-986 [4] http://issues.apache.org/jira/browse/TUSCANY-961 -- 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]
name of a service
Just now, I found that the service name=[name], name here must equal to the java interface's name, as well the service's name of WSDL, other wise, we just see NullPointerException. I would suggest generate a guiding Exception, to tell the developer this rule of defining a service. - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.
Re: [RDB DAS] Consistent use of Parameters in Config
I agree with Amita that for clarity is better to let the user set the parameter name, for all those reasons she has argued on this thread so far. But, I don't I agree with to use the [1] instead of [2], because it's not a good practice to define the parameter names on only one string separated by spaces, it's not a good practice, mainly when we're dealing with XML. My suggestion is to use [2], but add the xsd:attribute name=name type=xsd:string on Parameter ComplexType and also keep the index attribute on it. These way both methods, customer.set(pararmeterName, value) and customer.setParameter(parameterIndex, value) will be supported. However, on any of these cases, the user will need to define a parameter N times if there are N commands that use it. I don't see any solution for these case : ( Regards, Adriano Crestani [1]xsd:complexType name=Create xsd:attribute name=sql type=xsd:string/ xsd:attribute name=parameters type=xsd:string/ /xsd:complexType [2]xsd:complexType name=Create xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=Parameter type=config:Parameter/ /xsd:sequence xsd:attribute name=sql type=xsd:string/ /xsd:complexType On 8/2/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: 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
Re: Reference EJB Binding problem
We have done some further investigation and here are the findings: We have configured the J2SE enviroment to use Yoko ORB (the one used by Geronimo) instead of the JVMs and running the testcase resulted in a MarshalException. We suspect it is an issue with Yoko ORB. Vamsi On 8/3/07, ant elder [EMAIL PROTECTED] wrote: 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
Re: Reference EJB Binding problem
Hi, Thank you for the hint. I'm able to identify an issue in the Yoko ORB. The problem is in class: http://svn.apache.org/viewvc/incubator/yoko/trunk/core/src/main/java/org/apache/yoko/orb/CORBA/InputStream.java?revision=555715view=markup Method private String getIDLStubClassName(Class c) doesn't support the variant of stub names (org.omg.stub.*) defined by http://www.omg.org/docs/formal/03-09-04.pdf (section 1.4.6). As a workaround/fix, I changed the ejb binding code (EJBObjectFactory) to use org.omg.stub.javax.rmi._Remote_Stub.class to read the CORBA object. With this, the samples are now working fine on Geronimo 2.0 branch. The code was checked in under http://svn.apache.org/viewvc?view=revrev=562382. Thanks, Raymond - Original Message - From: Vamsavardhana Reddy [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:55 AM Subject: Re: Reference EJB Binding problem We have done some further investigation and here are the findings: We have configured the J2SE enviroment to use Yoko ORB (the one used by Geronimo) instead of the JVMs and running the testcase resulted in a MarshalException. We suspect it is an issue with Yoko ORB. Vamsi On 8/3/07, ant elder [EMAIL PROTECTED] wrote: 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 - 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
PITA is a new one on me. I usually use Google to help me in such cases, but most of the entries near the top of the list are about a kind of bread :-) I don't see this as such a big problem. The average WSDL file seems to contain at least 3 different namespaces. I think XML programmers are quite familiar with the need to define additional namespaces and how to do that. A simple rule that everything from the SCA spec is in the SCA namespace and everything from Tuscany SCA is in the Tuscany SCA namespace will help them to know which namespace they should be using. +1 to the suggestion that we produce extremely good diagnostics to help people who get the namespace wrong. Also +1 to the suggestion that we take Tuscany extensions that we think should be part of the specs to the spec group for their consideration. However, this does not avoid the need for multiple namespaces, because at any point in time we should expect to have some Tuscany extensions to SCA that are not (yet) part of the specs. This actually reinforces the importance of putting Tuscany extensions in a Tuscany namespace, because Tuscany's foo might get adopted as SCA's foo with subtle differences, and it will then be important for people to be able to write either tuscany:foo or sca:foo in their SCDL and get the correct semantics. Simon ant elder wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SDO sequenced DataObject vs XSD sequence
A Jira (https://issues.apache.org/jira/browse/TUSCANY-1504) has been raised against the SDO C++ implementation which is saying that for a schema: ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:letter=http://letterSchema; targetNamespace=http://letterSchema; xs:element name=letters type=FormLetter/ xs:complexType name=FormLetter xs:sequence xs:element name=date type=xs:string/ xs:element name=firstName type=xs:string/ xs:element name=lastName type=xs:string/ /xs:sequence /xs:complexType /xs:schema the complex type http://letterSchema#FormLetter; is not sequenced in SDO terms. I believe this is correct as the SDO use of the term sequenced is related to the order of the setting of the properties and in the above case maxOccurs=1 on the sequence and each of the contained elements.This means an instance of a FormLetter DataObject returns NULL for getSequence() in our implementation. So... is my interpretation of the spec correct? Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RDB DAS] Wrong Query Result when SELECT misses PKs
In RDBMS and in DAS OUTER JOINs are used quite frequently. By definition it means, all rows from parent and matching rows from child. So, there is a chance for having complete null rows from child and that is the purpose of OUTER JOIN. So there are different situations 1) complete child row is null (outer join case)- we should allow this, so that outer joins work :) 2) PK(single/compound) in child row is null, but some other columns have data - we should flag this case and throw exception 3) PK(single/compound) in parent row is null, but some other columns have data - we should flag this case and throw exception 4) complete parent row is null - allow :) , as anyways relationship will not be formed If we do not allow 1) 20 existing cases which use OUTER JOIN will fail, otherwise all existing cases succeed. So, instead of giving exception for Null data in PK columns, we can avoid those DOs in final Graph. But, absence of PK column (Type) itself from Result Set is another case, where there is no way to form the correct graph irrespective of values in the columns. Due to the above reasons, I am not doing the change in logic over Jul31 patch, but I am still uploading a new patch to fix 2 minor issues 1) name of the new xml file referred in test case was companyNoIDMappingWithConverters changing it to companynoidMappingWithConverters 2)if check in ResultSetProcessor.addRowToGraph() is made more complete to ensure no corner cases miss --- For the other question in JIRA-1464, please see the below explaination:- Question: 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? Ans: This will be true for Dynamic DO case, typically a query will be executed with ID column. COC will determine to treat it as PK. It will be used when registering new Type and Properties (SDO) in SDO context. And so when populating data in DOs, ID property will be found. But the change is done in company.xsd to take care of static DO scenario. Here, companyMappingWithConverters.xml refers to static model company.xsdand the generation of equiv java classes is before runtime. So, if ID is missing in company.xsd, ID will not be created in CompanyType...generated classes. After that in runtime, DAS will not be creating new Types and Properties for company as these are already in SDO context. Thus when populating DO with values from query, ID propery will not be found and exception will be thrown. Checked the same and get below exception. Example:- testSimpleStatic(org.apache.tuscany.das.rdb.test.CompanyTests) Time elapsed: 0. 18 sec ERROR! java.lang.RuntimeException: Type CompanyType does not contain a property named I Regards, Amita On 8/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: 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
Re: name of a service
According to line 1498 on page 34 of the Assembly spec[1] it doesn't sound like thats correct: 1498 • name (required) – the name of the service, the name MUST BE unique across all the 1499 composite services in the composite. The name of the composite service can be different 1500 from the name of the promoted component service. So the behaviour you're seeing sounds like a bug. Could you raise a JIRA, and if possible attach some code to demonstrate the problem? ...ant [1] http://www.oasis-opencsa.org/sca-assembly On 8/3/07, shaoguang geng [EMAIL PROTECTED] wrote: Just now, I found that the service name=[name], name here must equal to the java interface's name, as well the service's name of WSDL, other wise, we just see NullPointerException. I would suggest generate a guiding Exception, to tell the developer this rule of defining a service. - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.
[jira] Updated: (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:all-tabpanel ] Andy Grove updated TUSCANY-1397: Attachment: tuscany1397-v2.patch This patch replaces the previous version. This patch was created on the latest code. 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 Attachments: tuscany1397-v2.patch, tuscany1397.patch 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: Patch for TUSCANY-1397
Thanks Adriano, Fuhwei, I've re-created the patch using the trunk code as at revision 562418 and attached it to the JIRA. I'm happy to submit the patch directly if everyone is happy with the approach I'm taking on this issue. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: 03 August 2007 05:41 To: tuscany-dev@ws.apache.org Subject: 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/brow ser 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. - 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
Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: PITA is a new one on me. I usually use Google to help me in such cases, but most of the entries near the top of the list are about a kind of bread :-) I don't see this as such a big problem. The average WSDL file seems to contain at least 3 different namespaces. I think XML programmers are quite familiar with the need to define additional namespaces and how to do that. A simple rule that everything from the SCA spec is in the SCA namespace and everything from Tuscany SCA is in the Tuscany SCA namespace will help them to know which namespace they should be using. +1 to the suggestion that we produce extremely good diagnostics to help people who get the namespace wrong. Also +1 to the suggestion that we take Tuscany extensions that we think should be part of the specs to the spec group for their consideration. However, this does not avoid the need for multiple namespaces, because at any point in time we should expect to have some Tuscany extensions to SCA that are not (yet) part of the specs. This actually reinforces the importance of putting Tuscany extensions in a Tuscany namespace, because Tuscany's foo might get adopted as SCA's foo with subtle differences, and it will then be important for people to be able to write either tuscany:foo or sca:foo in their SCDL and get the correct semantics. Simon ant elder wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1438: --- Attachment: samples.CppBigBank.build.xml Uploading the build.xml file for the CppBigBank sample Change TuscanySCA Native build system to use ant Key: TUSCANY-1438 URL: https://issues.apache.org/jira/browse/TUSCANY-1438 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-Next Environment: all platforms Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: samples.CppBigBank.build.xml, tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, tuscany_patch_update6_jira1438, TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, tuscanySCAnative_ant_update1.tar.gz In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [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]
Re: name of a service
I'll jump in though I might be missing some context... ... I wonder if Shaoguang is describing the fact that the component service name must match the implementation service name when you are configuring the component via SCDL (rather than making a statement about the composite service name). This issue is particularly noticable when there is only one service in a component since in most places SCA lets you be ignorant of the service name of a single-service-component (e.g. when making a wire target). A guiding exception would be a nice addition... Scott On 8/3/07, ant elder [EMAIL PROTECTED] wrote: According to line 1498 on page 34 of the Assembly spec[1] it doesn't sound like thats correct: 1498 • name (required) – the name of the service, the name MUST BE unique across all the 1499 composite services in the composite. The name of the composite service can be different 1500 from the name of the promoted component service. So the behaviour you're seeing sounds like a bug. Could you raise a JIRA, and if possible attach some code to demonstrate the problem? ...ant [1] http://www.oasis-opencsa.org/sca-assembly On 8/3/07, shaoguang geng [EMAIL PROTECTED] wrote: Just now, I found that the service name=[name], name here must equal to the java interface's name, as well the service's name of WSDL, other wise, we just see NullPointerException. I would suggest generate a guiding Exception, to tell the developer this rule of defining a service. - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when.
Re: svn commit: r562291 - in /incubator/tuscany/java/sca/modules: binding-ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ej
Hi, Ant. Good point. It seems that Geronimo is very close to have the 2.0 release out and hopefully we can move to it soon. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 03, 2007 2:37 AM Subject: Re: svn commit: r562291 - in /incubator/tuscany/java/sca/modules: binding-ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/java2idl/ binding-ejb/src/main/java/org/apache/t Just a reminder we can't release with snapshot dependencies so we'll if there's something we require in these OpenEJB and Geronimo snapshots then we wont be able to include the EJB binding in a Tuscany release till there's non-snapshot releases we can use. ...ant On 8/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rfeng Date: Thu Aug 2 16:37:30 2007 New Revision: 562291 URL: http://svn.apache.org/viewvc?view=revrev=562291 Log: Improve the binding-ejb: * OpenEJB 3.0.0 SNAPSHOT and Geronimo 2.0 SNAPSHOT * Support for OpenEJB JNDI and CosNaming * Simplified Java2IDL Removed: incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/java2idl/ Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/EJBTargetInvoker.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/EJBHandler.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/EJBObjectFactory.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/InterfaceInfo.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/MethodInfo.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/NamingEndpoint.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/account/CustomerImpl.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/EJBReferenceTestCase.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/MockServer.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/SocketTracer.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/resources/account/account.composite incubator/tuscany/java/sca/modules/implementation-java-runtime/pom.xml Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ejb/pom.xml?view=diffrev=562291r1=562290r2=562291 == --- incubator/tuscany/java/sca/modules/binding-ejb/pom.xml (original) +++ incubator/tuscany/java/sca/modules/binding-ejb/pom.xml Thu Aug 2 16:37:30 2007 @@ -50,7 +50,7 @@ groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version -scoperuntime/scope +scopecompile/scope /dependency dependency @@ -85,11 +85,16 @@ !-- yuk. all the exclusions are necessary as otherwise just about every geronimo jar gets downloaded, and also there's a problem with one of the pom's causing the build to always fail -- - dependency -groupIdopenejb/groupId +groupIdorg.apache.openejb/groupId +artifactIdopenejb-client/artifactId +version3.0.0-SNAPSHOT/version +scopetest/scope +/dependency +dependency +groupIdorg.apache.openejb/groupId artifactIdopenejb-core/artifactId -version2.1.1/version +version3.0.0-SNAPSHOT/version scopetest/scope exclusions @@ -181,18 +186,22 @@ groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-servlet_2.4_spec/artifactId /exclusion -exclusion +!-- +exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId -/exclusion +/exclusion +-- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId /exclusion +!-- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jms_1.1_spec/artifactId /exclusion + -- exclusion
[jira] Updated: (TUSCANY-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1464: - Attachment: 1464.patch please see reply on ML Regards, Amita 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, 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: svn commit: r562291 - in /incubator/tuscany/java/sca/modules: binding-ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/ binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ej
Just a reminder we can't release with snapshot dependencies so we'll if there's something we require in these OpenEJB and Geronimo snapshots then we wont be able to include the EJB binding in a Tuscany release till there's non-snapshot releases we can use. ...ant On 8/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rfeng Date: Thu Aug 2 16:37:30 2007 New Revision: 562291 URL: http://svn.apache.org/viewvc?view=revrev=562291 Log: Improve the binding-ejb: * OpenEJB 3.0.0 SNAPSHOT and Geronimo 2.0 SNAPSHOT * Support for OpenEJB JNDI and CosNaming * Simplified Java2IDL Removed: incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/java2idl/ Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/EJBTargetInvoker.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/EJBHandler.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/EJBObjectFactory.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/InterfaceInfo.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/MethodInfo.java incubator/tuscany/java/sca/modules/binding-ejb/src/main/java/org/apache/tuscany/sca/binding/ejb/util/NamingEndpoint.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/account/CustomerImpl.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/EJBReferenceTestCase.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/MockServer.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/java/org/apache/tuscany/sca/binding/ejb/tests/SocketTracer.java incubator/tuscany/java/sca/modules/binding-ejb/src/test/resources/account/account.composite incubator/tuscany/java/sca/modules/implementation-java-runtime/pom.xml Modified: incubator/tuscany/java/sca/modules/binding-ejb/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ejb/pom.xml?view=diffrev=562291r1=562290r2=562291 == --- incubator/tuscany/java/sca/modules/binding-ejb/pom.xml (original) +++ incubator/tuscany/java/sca/modules/binding-ejb/pom.xml Thu Aug 2 16:37:30 2007 @@ -50,7 +50,7 @@ groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version -scoperuntime/scope +scopecompile/scope /dependency dependency @@ -85,11 +85,16 @@ !-- yuk. all the exclusions are necessary as otherwise just about every geronimo jar gets downloaded, and also there's a problem with one of the pom's causing the build to always fail -- - dependency -groupIdopenejb/groupId +groupIdorg.apache.openejb/groupId +artifactIdopenejb-client/artifactId +version3.0.0-SNAPSHOT/version +scopetest/scope +/dependency +dependency +groupIdorg.apache.openejb/groupId artifactIdopenejb-core/artifactId -version2.1.1/version +version3.0.0-SNAPSHOT/version scopetest/scope exclusions @@ -181,18 +186,22 @@ groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-servlet_2.4_spec/artifactId /exclusion -exclusion +!-- +exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId -/exclusion +/exclusion +-- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId /exclusion +!-- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jms_1.1_spec/artifactId /exclusion + -- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management_1.0_spec/artifactId @@ -249,10 +258,12 @@ groupIdconcurrent/groupId artifactIdconcurrent/artifactId /exclusion -exclusion +!-- +exclusion groupIdlog4j/groupId
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: PITA is a new one on me. I usually use Google to help me in such cases, but most of the entries near the top of the list are about a kind of bread :-) I don't see this as such a big problem. The average WSDL file seems to contain at least 3 different namespaces. I think XML programmers are quite familiar with the need to define additional namespaces and how to do that. A simple rule that everything from the SCA spec is in the SCA namespace and everything from Tuscany SCA is in the Tuscany SCA namespace will help them to know which namespace they should be using. +1 to the suggestion that we produce extremely good diagnostics to help people who get the namespace wrong. Also +1 to the suggestion that we take Tuscany extensions that we think should be part of the specs to the spec group for their consideration. However, this does not avoid the need for multiple namespaces, because at any point in time we should expect to have some Tuscany extensions to SCA that are not (yet) part of the specs. This actually reinforces the importance of putting Tuscany extensions in a Tuscany namespace, because Tuscany's foo might get adopted as SCA's foo with subtle differences, and it will then be important for people to be able to write either tuscany:foo or sca:foo in their SCDL and get the correct semantics. Simon ant elder wrote: 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] - 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
ant elder wrote: Taking that line of thought and you hit the long thread associated with: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] which is what I was hoping to quietly ignore by just keeping everything in the one SCA namespace. ...ant On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) I didn't really want to reopen this debate either but I didn't understand both of your last comments so I guess I'm going to have to ask some questions... Ant, what did you mean by having the Tuscany namespace extend the SCA one? Simon, I didn't understand your response either. Are you talking about an XSD element changing over time and when it'll change it'll break the runtime that supported the old one? Sure then... if the XSDs change then the runtime has to be updated as soon as you want to claim that you support the new one... I'm probably missing something really obvious :) Also I thought it'd be useful to post concrete examples of what we're talking about: What we currently have: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://aggregator; name=FeedAggregator service name=atomSample promote=AtomAggregator binding.atom uri=http://localhost:8083/atomAggregator/ /service component name=AtomAggregator implementation.java class=feed.AggregatorImpl/ reference name=feed1 binding.atom uri=http://www.oreillynet.com/pub/feed/1/ /reference reference name=feed2 binding.atom uri=http://www.apachenews.org/atom.xml/ /reference property name=feedTitleAtom Sample/property /component /composite With a new Tuscany namespace: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://www.apache.org/xmlns/tuscany/1.0; targetNamespace=http://aggregator; name=FeedAggregator service name=atomSample promote=AtomAggregator t:binding.atom uri=http://localhost:8083/atomAggregator/ /service component name=AtomAggregator implementation.java class=feed.AggregatorImpl/ reference name=feed1 t:binding.atom uri=http://www.oreillynet.com/pub/feed/1/ /reference reference name=feed2 t:binding.atom uri=http://www.apachenews.org/atom.xml/ /reference property name=feedTitleAtom Sample/property /component /composite And also give my opinion: +0.5 if people want to keep Tuscany extensions in the SCA namespace for now, hoping that they make it to the SCA spec XSDs at some point +1 for one Tuscany namespace for all our extensions, as it clearly flags the Tuscany added value -1 for one Tuscany namespace per extension as discussed in the long old thread you pointed, as it would be over complicated for application developers Finally here's an idea to help put a new spin on that discussion :) IMO application developers shouldn't have to suffer from the complexity of XML... How about supporting composites without namespace declarations at all? Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reference EJB Binding problem
Thanks Raymond. It works now. I will report the issue to Yoko mailing lists. Vamsi On 8/3/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Thank you for the hint. I'm able to identify an issue in the Yoko ORB. The problem is in class: http://svn.apache.org/viewvc/incubator/yoko/trunk/core/src/main/java/org/apache/yoko/orb/CORBA/InputStream.java?revision=555715view=markup Method private String getIDLStubClassName(Class c) doesn't support the variant of stub names (org.omg.stub.*) defined by http://www.omg.org/docs/formal/03-09-04.pdf (section 1.4.6). As a workaround/fix, I changed the ejb binding code (EJBObjectFactory) to use org.omg.stub.javax.rmi._Remote_Stub.class to read the CORBA object. With this, the samples are now working fine on Geronimo 2.0 branch. The code was checked in under http://svn.apache.org/viewvc?view=revrev=562382. Thanks, Raymond - Original Message - From: Vamsavardhana Reddy [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:55 AM Subject: Re: Reference EJB Binding problem We have done some further investigation and here are the findings: We have configured the J2SE enviroment to use Yoko ORB (the one used by Geronimo) instead of the JVMs and running the testcase resulted in a MarshalException. We suspect it is an issue with Yoko ORB. Vamsi On 8/3/07, ant elder [EMAIL PROTECTED] wrote: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for client application flexibility demo
Doug Tidwell wrote: Friends, I'm working on a demo to illustrate the flexibility SCA provides to client applications. I want to take the exact same code and use it to invoke different services using different access methods, etc., without changing the code. As I see it, there are three ways to do this. In order of elegance, imho, here are the three approaches: Put the name of the .composite file into a Java .properties file. When I call SCADomain.newInstance(x.composite), I replace x.composite with the property from the file. I can change the .properties file, re-run the code, and I get different behavior from the client application. Change the classpath so that the Java runtime finds one .composite file instead of another. Change the .composite file itself to point to a different service. Any advice on how I should do this? I prefer solution #1 because it's the most maintainable. I can use an XForms interface to read the different .composite files and select one or the other. The main thing I want to show is how to invoke different services in different ways without changing the client application at all. Cheers, -Doug p.s. I'll post the demo here as it matures, of course Great to hear that you're working on a new demo!! We have an sca/demos directory in SVN for demos, we could use more/better ones. Best will be to contribute pieces of your demo as you go attached to JIRA issues, and we'll be happy to help integrate them in SVN and the Tuscany build. To invoke different services in different ways without changing the client app at all, how about: - Using SCA includes, x.composite will contain an include name=ns:YComposite. An included composite can contain just wires, this will allow you to switch a whole wiring configuration easily, just go change x.composite to include YComposite or ZComposite for example - Using SCA composite implementations, x.composite will contain an implementation.composite name=ns:YComposite. This will allow you to switch the implementation of a big part of your application easily as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (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_12517584 ] Matthew Schultz commented on TUSCANY-1504: -- Check the spec but you might be right. I am able to access the properties directly through the root object. I figured that since a sequence was declared, it should be available within getSequence but apparently that may not be the case. Do you have a link for the spec? 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
On 8/3/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: Taking that line of thought and you hit the long thread associated with: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] which is what I was hoping to quietly ignore by just keeping everything in the one SCA namespace. ...ant On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) I didn't really want to reopen this debate either but I didn't understand both of your last comments so I guess I'm going to have to ask some questions... Ant, what did you mean by having the Tuscany namespace extend the SCA one? I'm not actually sure, my xsd is a bit rusty, i vaguely thought there was a way to say something extend another namespace inheriting all the things from it, but a quick search for it now i cant find how to do that, is it not possible? snip And also give my opinion: +0.5 if people want to keep Tuscany extensions in the SCA namespace for now, hoping that they make it to the SCA spec XSDs at some point I'd be +1 on doing that. The easier we can make things for people trying out Tuscany the better IHMO. ...ant
Re: [jira] Resolved: (TUSCANY-1495) LDAP DAS Contribution
Terrific - Thanks! Luciano Resende (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1495. -- Resolution: Fixed Patch applied under revision #562520 LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Ole Ersoy Assignee: Luciano Resende Priority: Minor Fix For: Java-DAS-Next Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1506) Fix RAT issues in DAS LDAP
Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA -- 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-1506) Fix RAT issues in DAS LDAP
[ https://issues.apache.org/jira/browse/TUSCANY-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1506: - Attachment: ldap-rat.log Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-761) Support the ability to unregister all the SDO Types in a namespace
[ https://issues.apache.org/jira/browse/TUSCANY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517504 ] Ron Gavlin commented on TUSCANY-761: Frank, I would not expect the runtime to manage dependencies in this case. Rather, it would be up to users to make sure they don't corrupt the registry. As Kelvin mentioned earlier, the introduction of HelperContext now provides a safe alternative to this unregistration in case users want to be sure they don't corrupt the registry. Support the ability to unregister all the SDO Types in a namespace -- Key: TUSCANY-761 URL: https://issues.apache.org/jira/browse/TUSCANY-761 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Fix For: Java-SDO-Next Add an SDO lifecycle metadata Tuscany extension to unregister all the SDO Types in a namespace. The suggested method is SDOUtil.unregisterTypes(TypeHelper typeHelper, String namespace). -- 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 0.92 release?
On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Another thing I wondered about was the name, we've been talking about this being 0.92, how about something higher to show we're getting closer, maybe 0.95 or 0.98 or even 0.99? (that prompts a what/when is 1.0, I'll start a separate thread about that) ...ant
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Taking that line of thought and you hit the long thread associated with: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] which is what I was hoping to quietly ignore by just keeping everything in the one SCA namespace. ...ant On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: Wouldn't this cause breakage in the scenario that I described, where foo from Tuscany later turns into foo as part of SCA but with some differences? Any SCDLs written to just use plain foo would break when Tuscany steps up to support the SCA foo. Simon ant elder wrote: How about having the Tuscany namespace extend the SCA one so you can choose to use that as the default namespace so as to avoid having to worry about all the namespace prefixes? ...ant I don't really expect to win this debate now that the issue has been brought up, had just been hoping it wouldn't come up :) On 8/3/07, Simon Nash [EMAIL PROTECTED] wrote: PITA is a new one on me. I usually use Google to help me in such cases, but most of the entries near the top of the list are about a kind of bread :-) I don't see this as such a big problem. The average WSDL file seems to contain at least 3 different namespaces. I think XML programmers are quite familiar with the need to define additional namespaces and how to do that. A simple rule that everything from the SCA spec is in the SCA namespace and everything from Tuscany SCA is in the Tuscany SCA namespace will help them to know which namespace they should be using. +1 to the suggestion that we produce extremely good diagnostics to help people who get the namespace wrong. Also +1 to the suggestion that we take Tuscany extensions that we think should be part of the specs to the spec group for their consideration. However, this does not avoid the need for multiple namespaces, because at any point in time we should expect to have some Tuscany extensions to SCA that are not (yet) part of the specs. This actually reinforces the importance of putting Tuscany extensions in a Tuscany namespace, because Tuscany's foo might get adopted as SCA's foo with subtle differences, and it will then be important for people to be able to write either tuscany:foo or sca:foo in their SCDL and get the correct semantics. Simon ant elder wrote: 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
Re: SCA 0.92 release?
Hi Ant... thanks for bringing this up again. Yes, the week ending Aug 17th seems good if we plan to release end of August. I'd prefer 0.95 for the next release. - Venkat On 8/3/07, ant elder [EMAIL PROTECTED] wrote: On 6/30/07, ant elder [EMAIL PROTECTED] wrote: With the SCA 0.91 release now being voted on how about starting on 0.92? I've already been adding some things I'm interested in getting done to the next release wiki page - http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents- so far thats mainly related to improving web services functionality. So anyone else interested in helping with an 0.92 release or have any function they'd like to suggest or add to the wiki page? How does aiming for getting it done 4 - 6 weeks again sound? ...ant Bringing this thread up again as time is ticking on if we want to get a release out this month. How would people feel about taking a branch for this release in a bit less than 2 weeks, say aiming for the 14/15th of August? That should just about give enough time for clean up and voting to get a release out by the end of August. Another thing I wondered about was the name, we've been talking about this being 0.92, how about something higher to show we're getting closer, maybe 0.95 or 0.98 or even 0.99? (that prompts a what/when is 1.0, I'll start a separate thread about that) ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
ant elder wrote: On 8/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. After more reading of the various SCA specs, I think we should defer supporting a domain URI (or a set of domain URIs) until the specs clarify the use cases for it. Here are the issues I'm seeing: - Component URI is not clearly defined in the spec (there's an errata for this), the name of the component cannot be used alone for nested components, and concatenating names of nested components with a domain URI is likely to cause ambiguities and collisions. - Having a domain URI per node in a domain (proposed earlier in this thread) is not in line with the spec. - Also doing that will burn the node topology in the SCA domain logical assembly, as you'll see the addresses of your nodes in the URIs on your reference bindings, so the logical assembly won't be so logical anymore :) - We could say that the domain URI is just a logical URI, but then I don't understand why we would need it at all, as specifying domainURI/someURI in the URI of a reference binding would only compete with the target attribute of a reference or wire. - And if it was just a logical URI then I'm not sure why we'd need a different URI per protocol. So at this point I don't understand how this domain URI was intended to be used and I think we should keep things simple. I'd suggest to not try to use a domain URI to calculate any binding URIs for now, and ask application developers and assemblers to specify the URIs they want explicitly. If anyone out there has a requirement for domain URIs and can articulate the use case and how it should work, please shout :) Finally, the SCA assembly model is already able to store a single URI in the domain's Composite model object (see Composite.get/setURI()), so if people find a real use case and are OK to start with a single domain URI, they can just use that. Thoughts? So what is the proposal exactly - ask application developers and assemblers to specify the URIs they want explicitly - could there be some examples of what that would mean for our various http based bindings? ...ant I'm just proposing to continue to do what we already do today, without introducing a domain base URI configuration now as it's unclear at this point how it's going to be used and how it should work. Here are two sample composite files:
Re: [jira] Created: (TUSCANY-1506) Fix RAT issues in DAS LDAP
Hi Luciano, I looked at the RAT log and noticed that I ended up including the server-work directory in the zip. Could you please delete this from subversion. The server-work directory is created when ApacheDS is started in embedded mode by the tests. I'll start patching the non-licensed java files, as well as adding more detailed javadocs. Thanks, - Ole Luciano Resende (JIRA) wrote: Fix RAT issues in DAS LDAP -- Key: TUSCANY-1506 URL: https://issues.apache.org/jira/browse/TUSCANY-1506 Project: Tuscany Issue Type: Bug Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Luciano Resende Fix For: Java-DAS-Next Attachments: ldap-rat.log Running rat on the LDAP source flaged couple issues that we should look at. I'll attach the rat.log to this JIRA - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
[snip] Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516845 ] Jean-Sebastien Delfino commented on TUSCANY-1499: - I'd suggest the following to further simplify this: State that a reference with a callback cannot be named like a service State that a service with a callback cannot be named like a reference Take these statements as proposals to the SCA spec workgroup. This will save us from having to implement a complicated naming convention for the derived callback services and callback references, and will save the application developer to have to understand it. I think that this is a reasonable approach for now, as Java components for example will typically name a reference foo and a service Foo, and as another example BPEL components already have this naming limitation as well if I understand BPEL and WSDL correctly. I don't think convenience of the runtime (one particular runtime) should be made visible at the spec level. We should take the spec as is and do what we need to support it. This won't be very difficult. The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. On the other hand, I'm observing that: - 99% of Java components name their services and references differently (actually 100% of the ones I've seen implemented so far) - (unless i'm mistaken about BPEL) 100% of BPEL components will name them differently - and IIRC earlier versions of the SCA assembly spec had this rule as well, at least in composite implementations (before the service/reference promotion mechanism was introduced). So instead of implementing an ugly naming convention (necessarily ugly to avoid naming collisions), and exposing it to application developers... I'd rather go with an acceptable limitation, which may actually make it back to the spec. I'll raise this as as an issue to the SCA assembly spec work group. Define marker interfaces ComponentCallbackService extends ComponentService and ComponentCallbackReference extends Reference to allow code like domain.locateService to filter out these callback services/references and not allow them to be located explicitly. I'd be more inclined to do this using a method isCallback() on the Contract interface from which services and references inherit. +1 Instead of trying to establish callback wires all over the place, which will not fly anyway as soon as 2 references with callback are wired to a single service, flow the endpoint reference of the callback service representing the client in the SCA request message and use it to direct the callback in context as suggested by Raymond in thread [1]. These callback wires are already being established and AFAIK this does work in the case you describe. The callback wire is selected based on the forward wire that was used. I'll write an itest to verify that this is working correctly. Already covered in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21065.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use the contribution URI as the scope for HelperContext, was Fwd: svn commit: r561111 - /incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/Imp
[snip] Luciano Resende wrote: I have fixed this under revision #561972, we now utilize the contribution file name or it's location (in case of a folder) to construct the contribution URI. On 7/30/07, Luciano Resende [EMAIL PROTECTED] wrote: Looks like DefaultSCADomain is always setting contributionURI to empty string. With the current behavior, can we have side effects by using the contributionURI as the scope for HelperContext ? Here is a output I get after setting a System.out inside DefaultSCADomain(line 113) and ImportSDOPostProcessor (line 117), and then executing the helloworld-ws-sdo sample. contributionURI = HelperContext ID: contributionURI = HelperContext ID: addServletMapping port: 8085 path: /HelloWorldService Injected helloWorldService Called getGreetings Thoughts ? I've just started to look into this and I'm not quite sure how associating an SDO HelperContext with a contribution URI is going to work. I may be missing something as I've not looked at HelperContext for a while. Here's the scenario that I'm interested in: - I'm using XSDs to describe my business data, for example CustomerBusinessObject.xsd describes http://myns#CustomerBusinessObject representing a Customer business object. - I'm using SDOs as well, and I have generated an SDO class for my business objects: myns.CustomerBusinessObject - I'm using CustomerBusinessObject in all my applications so I have packaged CustomerBusinessObject.xsd and myns.CustomerBusinessObject in an SCA contribution which I'm going to reuse everywhere: Customer.jar - I'm developing a CustomerService SCA service component, in contribution CustomerService.jar - CustomerService.jar uses SCA imports to import the Customer business object XML namespace and generated SDO class: import namespace=http://myns; location=Customer.jar/ import.java package=myns location=Customer.jar/ - the CustomerService component gets the HelperContext associated with CustomerService.jar (right?), and uses it to work with a CustomerBusinessObject. Does that basic scenario work? Will the SDO HelperContext obtained in CustomerService.jar see the SDO metadata and class for CustomerBusinessObject from Customer.jar? I think it should :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Group and artifact id for commonj Work and Timer APIs, was: [Java SDO, SCA and DAS] change of group id and artifact name for sdo api maven artifact
Raymond Feng wrote: Hi, Is it different from http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-commonj_1.1_spec/1.0/? If not, we can use the geronimo one and remove our own. Otherwise, renaming the artifact id to tuscany-commonj-api sounds good to me. Thanks, Raymond Good catch, it doesn't look very different, I'll try to see if we can just use it. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL implementation: WSDL and BPEL resolving
Hi Raymond, Sorry for the late reply, your e-mail passed through my filters :) The approach described in the document sounds good to me, it's similar to what we're doing for import resolution within an ODE deployment package. So that should work. The only part I'm not so clear about though is when the resolution occurs, is it when the contribution is loaded? And thanks for the congrats! Matthieu On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Matthieu. Congratulations on the ODE graduation! We have made some processes in Tuscany regarding to the artifact resolving. Please see more details at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts . I think the strategy will apply to BPEL as well. Would you please take a look? Hopefully, we can get the implementation.bpel working soon. Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: Luciano Resende [EMAIL PROTECTED] Cc: tuscany-dev@ws.apache.org Sent: Thursday, July 05, 2007 5:08 PM Subject: Re: BPEL implementation: WSDL and BPEL resolving Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: BPEL implementation: WSDL and BPEL resolving
The loading of contribution has two phases : read and resolve. * read phase : This is where you read an artifact (a document, an XML element, classes etc.), populate a model representing the artifact and return it. The SCA contribution service calls ArtifactProcessor.read() on all artifacts that have an ArtifactProcessor registered for them. If your model points to other models, instead of trying to load these other models right away, you should just keep the information representing that reference, which you'll turn into a pointer to the referenced model in the resolve() phase. Note that you don't necessarily need to fully read and populate your model at this point, you can choose to complete it later. * resolve phase : This phase gives you the opportunity to resolve references to other models (a WSDL, a class, another composite, a componentType). At this point, all models representing the artifacts in your SCA contribution have been read, registered in the contribution's ArtifactResolver, and are ready to be resolved. The resolution is going to happen when the contribution is loaded, and my understanding is that some recent changes from Raymond will also make some loading/resolution only happen if the artifact is indeed referenced. Some more info here [1] [1] http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide On 8/3/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi Raymond, Sorry for the late reply, your e-mail passed through my filters :) The approach described in the document sounds good to me, it's similar to what we're doing for import resolution within an ODE deployment package. So that should work. The only part I'm not so clear about though is when the resolution occurs, is it when the contribution is loaded? And thanks for the congrats! Matthieu On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Matthieu. Congratulations on the ODE graduation! We have made some processes in Tuscany regarding to the artifact resolving. Please see more details at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts . I think the strategy will apply to BPEL as well. Would you please take a look? Hopefully, we can get the implementation.bpel working soon. Thanks, Raymond - Original Message - From: Matthieu Riou [EMAIL PROTECTED] To: Luciano Resende [EMAIL PROTECTED] Cc: tuscany-dev@ws.apache.org Sent: Thursday, July 05, 2007 5:08 PM Subject: Re: BPEL implementation: WSDL and BPEL resolving Sure, no problem. And thanks :-) On 7/5/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Matthieu I'm little overbooked these days, but let me see if I could try to look into the resolution thing over the weekend. Is that OK ? On 7/5/07, Matthieu Riou [EMAIL PROTECTED] wrote: Hi guys, I've done a few additional stuff on the BPEL implementation allowing a BPEL file to be compiled by ODE upon deployment. The implementation is therefore created and initialized with most of what would be needed by the runtime. However there's still a couple of problems with resolution and finding my way inside Tuscany code isn't that easy. To resolve the WSDL implemented by the process I've been trying to go through the resolution mechanism and declare the implementation I return in the read() method of the processor as unresolved. However the resolve() method is never called afterward and this results in a NullPointerException in Tuscany as the InterfaceContract is never set. From what I could make out of the code, it seems that the resolution mechanism happens for Interface processors but not of implementations, but I could be wrong. I've created a patch that adds the BPEL compilation and demonstrates the problem using the test case. Please have a look at BPELImplementationProcessor, you'll see how the implementation is built. You'll also see that the BPEL file from now is directly loaded using an additional file attribute. Ideally that should go as well to use the same type of resolving as for the WSDL (when it will work). Some help regarding this would be definitely welcome... Thanks, Matthieu -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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] 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_12517631 ] Adriano Crestani commented on TUSCANY-1464: --- Replies on http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20244.html 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, 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
Hi Amita, Great work you are doing : ). You are correct about the outer join case, I hadn't remember this use case. Yes, DAS should ignore a row completely null, but only when it's completely null, any other data in it, DAS should throw an exception. Thanks for the explanation about the static id column. I wasn't aware enough about how static DO works : ( Regards, Adriano Crestani On 8/3/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: In RDBMS and in DAS OUTER JOINs are used quite frequently. By definition it means, all rows from parent and matching rows from child. So, there is a chance for having complete null rows from child and that is the purpose of OUTER JOIN. So there are different situations 1) complete child row is null (outer join case)- we should allow this, so that outer joins work :) 2) PK(single/compound) in child row is null, but some other columns have data - we should flag this case and throw exception 3) PK(single/compound) in parent row is null, but some other columns have data - we should flag this case and throw exception 4) complete parent row is null - allow :) , as anyways relationship will not be formed If we do not allow 1) 20 existing cases which use OUTER JOIN will fail, otherwise all existing cases succeed. So, instead of giving exception for Null data in PK columns, we can avoid those DOs in final Graph. But, absence of PK column (Type) itself from Result Set is another case, where there is no way to form the correct graph irrespective of values in the columns. Due to the above reasons, I am not doing the change in logic over Jul31 patch, but I am still uploading a new patch to fix 2 minor issues 1) name of the new xml file referred in test case was companyNoIDMappingWithConverters changing it to companynoidMappingWithConverters 2)if check in ResultSetProcessor.addRowToGraph() is made more complete to ensure no corner cases miss --- For the other question in JIRA-1464, please see the below explaination:- Question: 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? Ans: This will be true for Dynamic DO case, typically a query will be executed with ID column. COC will determine to treat it as PK. It will be used when registering new Type and Properties (SDO) in SDO context. And so when populating data in DOs, ID property will be found. But the change is done in company.xsd to take care of static DO scenario. Here, companyMappingWithConverters.xml refers to static model company.xsdand the generation of equiv java classes is before runtime. So, if ID is missing in company.xsd, ID will not be created in CompanyType...generated classes. After that in runtime, DAS will not be creating new Types and Properties for company as these are already in SDO context. Thus when populating DO with values from query, ID propery will not be found and exception will be thrown. Checked the same and get below exception. Example:- testSimpleStatic(org.apache.tuscany.das.rdb.test.CompanyTests) Time elapsed: 0. 18 sec ERROR! java.lang.RuntimeException: Type CompanyType does not contain a property named I Regards, Amita On 8/2/07, Adriano Crestani [EMAIL PROTECTED] wrote: 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
Re: Patch for TUSCANY-1397
Applyed the new patch, tests ran OK, commited. Adriano Crestani On 8/3/07, Andy Grove [EMAIL PROTECTED] wrote: Thanks Adriano, Fuhwei, I've re-created the patch using the trunk code as at revision 562418 and attached it to the JIRA. I'm happy to submit the patch directly if everyone is happy with the approach I'm taking on this issue. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: 03 August 2007 05:41 To: tuscany-dev@ws.apache.org Subject: 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/brow ser 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1397
Hey Andy, It should be OK for you to committ it directly, if you need a review just forward the committ log and ask people to review (but I guess they will be reviewing it anyway from the mail notifications). On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Andy, please, check if everything was commited as expected to resolve the JIRA1397. Regards, Adriano Crestani On 8/3/07, Adriano Crestani [EMAIL PROTECTED] wrote: Applyed the new patch, tests ran OK, commited. Adriano Crestani On 8/3/07, Andy Grove [EMAIL PROTECTED] wrote: Thanks Adriano, Fuhwei, I've re-created the patch using the trunk code as at revision 562418 and attached it to the JIRA. I'm happy to submit the patch directly if everyone is happy with the approach I'm taking on this issue. Thanks, Andy. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adriano Crestani Sent: 03 August 2007 05:41 To: tuscany-dev@ws.apache.org Subject: 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/brow ser 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. - 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: [VOTE] Release Tuscany Java DAS beta1 (RC3)
+1 The sample artifacts aren't really be distributed in the maven repository are they so should be deleted from the temp repo? Also none of the maven artifacts are signed. Both of those can be fixed keeping the release distributions as-is though without a requiring any respin. A lot of the LICENSE files included unnecessary licenses,and the NOTICE files include the incubation disclaimer text even though there's a separate DISCLAIMER file. Can fix these next release though. I can't verify the signatures on this machine, hopefully someone has checked them? ...ant 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]
Re: Group and artifact id for commonj Work and Timer APIs, was: [Java SDO, SCA and DAS] change of group id and artifact name for sdo api maven artifact
Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, Is it different from http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-commonj_1.1_spec/1.0/? If not, we can use the geronimo one and remove our own. Otherwise, renaming the artifact id to tuscany-commonj-api sounds good to me. Thanks, Raymond Good catch, it doesn't look very different, I'll try to see if we can just use it. Under revision r562626 I have ported the tuscany-core module to the commonj-api from Geronimo, which was almost identical to the Tuscany commonj-api (the schedule methods were just throwing IllegalArgumentExceptions instead of WorkExceptions). Since it's not used anymore, if there is no objection I'd like to move sca/modules/commonj-api to sandbox/contrib out of the main build, planning to do this end of day on Monday. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
