[jira] Closed: (TUSCANY-1087) DAS should not commit individual commands as part of applyChanges
[ https://issues.apache.org/jira/browse/TUSCANY-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Williams closed TUSCANY-1087. --- Resolution: Fixed Verified in revision: 502521 > DAS should not commit individual commands as part of applyChanges > - > > Key: TUSCANY-1087 > URL: https://issues.apache.org/jira/browse/TUSCANY-1087 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-DAS-Mx >Reporter: Kevin Williams > Fix For: Java-DAS-Mx > > > The DAS must commit all commands resulting from ChangeSummary processing as > an atomic unit. > Sam Su's original note: > "Hi kevin, thanks for you response. > I debuged the application in Eclipse, I was sure that after user1 was > inserted into database without an exception, a commit was performed on the > connection. > as two data objects needed to be inserted into database in my program, from > the DAS source code, DAS will produce two different InsertCommandImpl > instances for these two changes.The 'success' flag is in two different > command instance, furthermore, it's a method scope variable, it can not be > shared between two command instances. When command instance for user1 > execute without an exception, it will proceed to perform a commit on the > connection, command instance for user2 execute will throw an exception, so > rollback. However the use1 has been already commited to database although > use2 fail to be inserted into database." > I have added a test "TransactionTests.estReadModifyApply()" t hat > demonstrates this defect. -- 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]
Developing extension code with latest kernel?
Hi, Most of the extensions in the trunk depend on the pre-spec-changes-SNAPSHOT version of the kernel. What should I do if I want to start to evolve an extension (for example, databinding-sdo) with the latest kernel? I think of the following steps: 1) Copy the code to pre-spec-changes branch and publish SNAPSHOTs to maven 2) Update the code in trunk to reference the latest version (1.0-incubator-SNAPSHOT) of kernel Does it make sense? Thanks, Raymond
Re: [jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML
Hi, Ed Merks and I did some work on this (Mostly Ed :-) ). I skimmed the JIRA briefly, and I think this applies here: See https://bugs.eclipse.org/bugs/show_bug.cgi?id=166127 Here's a brief summary: Case1: The element is supposed to be namespaced, but is not. Case2: The element is namespaced, but should not be. Case3: The element is namespaced, but the namespace is different from the namespace that the element is supposed to have per the schema definition. The redesigne of BasicExtendedMetaData supports cases 1 & 2 with a single switch. Hopefully the new design of the BasicExtendedMetaData applies to this TUSCANY-1088 Cheers, - Ole --- "Kevin Williams (JIRA)" wrote: > > [ > https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Kevin Williams updated TUSCANY-1088: > > > Description: > I had some off-line discussion with Frank and Yang. > Here is the summary: > > As an improvement to consumability, SDO should > tolerate some malformed XML. XML documents are > often less than well-formed. Rather than failing on > deserialization when a document does not completely > conform to its schema, we should consider making > some assumptions and continuing on. Some competitor > technologies do this today. > > Here's an example. Say we have this schema: > > > targetNamespace="http://QuickTest/HelloWorld"; > xmlns:tns="http://QuickTest/HelloWorld"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified"> > > > > type="xsd:string" /> > > > > > > If we get an xml that looks like this: > > > xmlns:tns="http://QuickTest/HelloWorld"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://QuickTest/HelloWorld > HelloWorldMessage.xsd "> > input1 > > > then we will fail validating this since input1 isn't > fully qualified. Here's the xml that would work: > > > xmlns:tns="http://QuickTest/HelloWorld"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://QuickTest/HelloWorld > HelloWorldMessage.xsd "> > tns:input1 > > > Frank mentioned 2 potential approaches: > > 1. Read the element in as if it was an open > content property. If you reserialize it would be the > same (still invalid). > 2. If a property with the same name (but different > namespace) exists, then associate it with that. When > you reserialize it will be then be correct. > > The later seems the best approach. > > Yang also contributed the following: > > It's friendly to tolerate if a user forgets to > qualify a local element. There're 3 scenarios may > not have the same elementFormDefault="qualified" > enforcement policy. What do you think? > > 3-1. xmlns:tns="http://QuickTest/HelloWorld";> > input1 > > > The author may have forgot to qualify "input1" > element, although "input1" may also be a global > element without NameSpace. > It's friendly to tolerate. > > 3-2. xmlns:tns="http://QuickTest/HelloWorld"; > xmlns:onPurpose="differentNameSpace"> > input1 > > The author has qualified "input1" element; I'm not > confident we should tolerate. > > 3-3. xmlns:tns="http://QuickTest/HelloWorld"; > xmlns="differentNameSpace"> > input1 > > It's hard to tell if the author may have forgot to > qualify "input1" element or not. > I bet on not. Should we tolerate? > > > > > > > > was: > I had some off-line discussion with Frank and Yang. > Here is the summary: > > As an improvement to consumability, SDO should > tolerate some malformed XML. It is not uncommon for > XML documents to not be less than well-formed. > Rather than failing on deserialization when a > document does not completely conform to its schema, > we should consider making some assumptions and > continuing on. Some competitor technologies do this > today. > > Here's an example. Say we have this schema: > > > targetNamespace="http://QuickTest/HelloWorld"; > xmlns:tns="http://QuickTest/HelloWorld"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified"> > > > > type="xsd:string" /> > > > > > > If we get an xml that looks like this: > > > xmlns:tns="http://QuickTest/HelloWorld"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://QuickTest/HelloWorld > HelloWorldMessage.xsd "> > input1 > > > then we will fail validating this since input1 isn't > fully qualified. Here's the xml that would work: > > > xmlns:tn
[jira] Updated: (TUSCANY-1088) SDO should tolerate malformed XML
[ https://issues.apache.org/jira/browse/TUSCANY-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Williams updated TUSCANY-1088: Description: I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. XML documents are often less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: http://QuickTest/HelloWorld"; xmlns:tns="http://QuickTest/HelloWorld"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"> If we get an xml that looks like this: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> input1 then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> tns:input1 Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault="qualified" enforcement policy. What do you think? 3-1.http://QuickTest/HelloWorld";> input1 The author may have forgot to qualify "input1" element, although "input1" may also be a global element without NameSpace. It's friendly to tolerate. 3-2.http://QuickTest/HelloWorld"; xmlns:onPurpose="differentNameSpace"> input1 The author has qualified "input1" element; I'm not confident we should tolerate. 3-3.http://QuickTest/HelloWorld"; xmlns="differentNameSpace"> input1 It's hard to tell if the author may have forgot to qualify "input1" element or not. I bet on not. Should we tolerate? was: I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. It is not uncommon for XML documents to not be less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: http://QuickTest/HelloWorld"; xmlns:tns="http://QuickTest/HelloWorld"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"> If we get an xml that looks like this: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> input1 then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> tns:input1 Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault="qualified" enforcement policy. What do you think? 3-1.http://QuickTest/HelloWorld";> input1 The author may have forgot to qualify "input1" element, although "input1" may also be a global element without NameSpace. It's friendly to tolerate. 3-2.http://QuickTest/HelloWorld"; xmlns:onPurpose="differentNameSpace"> input1 The author has quali
[jira] Created: (TUSCANY-1088) SDO should tolerate malformed XML
SDO should tolerate malformed XML - Key: TUSCANY-1088 URL: https://issues.apache.org/jira/browse/TUSCANY-1088 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Kevin Williams Fix For: Java-SDO-Mx I had some off-line discussion with Frank and Yang. Here is the summary: As an improvement to consumability, SDO should tolerate some malformed XML. It is not uncommon for XML documents to not be less than well-formed. Rather than failing on deserialization when a document does not completely conform to its schema, we should consider making some assumptions and continuing on. Some competitor technologies do this today. Here's an example. Say we have this schema: http://QuickTest/HelloWorld"; xmlns:tns="http://QuickTest/HelloWorld"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified"> If we get an xml that looks like this: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> input1 then we will fail validating this since input1 isn't fully qualified. Here's the xml that would work: http://QuickTest/HelloWorld"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://QuickTest/HelloWorld HelloWorldMessage.xsd "> tns:input1 Frank mentioned 2 potential approaches: 1. Read the element in as if it was an open content property. If you reserialize it would be the same (still invalid). 2. If a property with the same name (but different namespace) exists, then associate it with that. When you reserialize it will be then be correct. The later seems the best approach. Yang also contributed the following: It's friendly to tolerate if a user forgets to qualify a local element. There're 3 scenarios may not have the same elementFormDefault="qualified" enforcement policy. What do you think? 3-1.http://QuickTest/HelloWorld";> input1 The author may have forgot to qualify "input1" element, although "input1" may also be a global element without NameSpace. It's friendly to tolerate. 3-2.http://QuickTest/HelloWorld"; xmlns:onPurpose="differentNameSpace"> input1 The author has qualified "input1" element; I'm not confident we should tolerate. 3-3.http://QuickTest/HelloWorld"; xmlns="differentNameSpace"> input1 It's hard to tell if the author may have forgot to qualify "input1" element or not. I bet on not. Should we tolerate? -- 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: [C++] Interface descriptions and type conversions
Simon Laws wrote: On 2/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Simon Laws wrote: > I notice in implementing the PHP extension (yes - believe it or not I'm > nearly ready to make a patch for the next version ;-) that, given the way > that I have implemented the PHP extension there is insufficient > information > available in the SCA runtime in order to do correct type conversions when > passing messages between components. I imagine this has been raised > before > but I looked at the archive and couldn't find a relevant thread. > > Imagine the scenario: > > C++ Component (ComponentA) ---WireA---> PHP Component (ComponentB) > ---WireB> C++ Component (ComponentC) > > Currently the build process looks at the header files described in the > component type files and generates wrappers and proxies for the C++ > components. I have currently implemented the PHP Extension to use generic > wrappers and proxies, i.e. it doesn't use those generated based on the > interface descriptions, so they need to dynamically manage the type > conversions for data coming in and going out of a PHP component. > > WireA. > > This is OK because the C++ SCA operation object that appears at > Component B > has a set of data/types based on the generated proxy. The PHP > extension can > look at this and effect the right type conversions. > > WireB > > This is problematic. The dynamic PHP proxy has to generate an operation > object to pass to the the wrapper of ComponentC. The issue is that > there is, > as far as I can tell, no dynamic way of getting at the list of types that > are expected for any particular operation. There is of course a static > C++ > proxy/wrapper combination that has been generated but I can't inspect > it at > runtime. > > I'm not keen on generating PHP specific interface classes. PHP is a > dynamic > environment and it's a whole stack of extra files we could do without > having > to manage particularly if we have to adapt the generator for every > extension > that's constructed. Can we extend the wrapper/proxy mechanism to > encapsulate > a runtime list of required types alongside the static method descriptions > that are already generated? We would need this to work for script to > script > calls as well as for the script/C++ combination so maybe we need > something > that hangs off the interface description part of the model. I'm not that > familiar with how that part of the model is used so a little > investigation > is required. > > Thoughts? > > Simon > Simon, It's an interesting issue. To explore it let's walk through the wiring scenario you describe and assume the following: - ComponentA (C++) -> WireA -> ComponentB (PHP) -> WireB -> ComponentC (C++) - ComponentA (C++) passes a short int to ComponentB (PHP) - ComponentB executes a PHP script which in turn passes a number to ComponentC (C++) - ComponentC expects that number to be given as a long int. Here's what I think should happen in the runtime: 1. At the source of WireA, a generated C++ CPPServiceProxy adds to our Operation object a Parameter of a type decided by the C++ client code: a C++ short int, with type == ParameterType::SHORT. 2. At the end of WireA, a PHPServiceWrapper converts that parameter to what the PHP script expects, for the sake of simplicity now I am going to assume that it needs to convert it to a C++ std::string. 3. The PHP script executes, now passes an std::string containing a number to the PHPServiceProxy at the source of WireB. 4. The PHPServiceProxy does not have much type info about that std::string parameter and can only add it to the Operation object as a std::string with type == ParameterType::STRING. 5. The CPPServiceWrapper at the end of WireB (actually the C++ ServiceWrapper generated for ComponentC) receives the std::string and should convert it to what ComponentC expects: a long int. The general idea is that a ServiceProxy sends what it is given (or picks the most natural type out of the ParameterTypes that we have defined and converts the data to it). A ServiceWrapper converts what it receives to the type expected by the code it wraps. I think that the CPPServiceWrapper code and the generated C++ ServiceWrappers are simply missing the logic to convert data to what the target expects. At the moment this limitation also prevents a C++ method getCustomer(long customerID) to be exposed as a REST service for example, as the generated C++ ServiceWrapper is missing the logic to convert the customerID received in string form from the REST query string to the expected C++ long int. So we just need to add the missing type conversion logic to the C++ ServiceWrappers :) Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Jean-Sebastien It could well be simpler if, as you suggest, the conversion happens in the generated wrapper in this case
New Wiki page to help capture Tuscany requirements
I have started to work on a Wiki page capturing the various requirements that I've gathered from browsing the SCA specs and discussions on the Tuscany dev list, and the work in-progress in our community. The page is at http://cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what+folks+are+working+on. I am hoping that it will help organize our requirements and discuss how we want to stage their implementation over our next milestones. It should also help new contributors understand who is working on what, and grab areas that need work. I started today with some requirements related to the SCA assembly programming model and plan to add more tomorrow. This is just a starting point and I'd like to invite everybody in our community to come help build that page with the requirements that they are aware of, and the features that they are interested in. BTW, this Confluence Wiki is much easier to use than our previous Wiki :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA Java C&I spec questions
Hi, I have a few questions about the latest SCA Java C&I spec. For those who involve in the spec discussions, I would appreciate if you can clarify. 1) For annotations such as @Property, @Reference and @Service, should we annotate them with @Inherited so that these annotations can be inherited by subclasses? 2) For @Property, is it desirable to define the XSD "type" or "element" as defined in the assembly spec? 3) To derive the service name from a java interface, should the fully-qualied class name be used to avoid conflicts (such as a.Service and b.Service) or we should add an optional name attribute to @Service to customize the service name if necessary? 4) What kind of java interfaces are qualified to be remotable? Are the parameter/return type required to be Serializable or? 5) The spec says WSDL2Java follows the JAX-WS spec. Should we then honor the JAX-WS annotations in the generated interfaces? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing kernel/runtime/samples to new apis
I have updated kernel to use the new spec apis but also need to make changes to the runtime code (the host code) and the samples. I can either check in what I have so far which will break the runtime module in the trunk, or I can press on until everything is converted (which will be a much bigger patch to assimilate). In the interests of little&often, unless anyone objects I'll apply the change to the kernel tomorrow morning PST and patch the build for runtime so that the unit tests pass but it won't actually run. I'll then make smaller changes to the runtime and core samples to reflect the changes. I'd expect to be able to run the basic core samples late tomorrow or early Sat. Thanks -- Jeremy kernel patch attached, hoping it does not get stripped - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LDAP DAS
Perfect. Full speed ahead :-) --- Luciano Resende <[EMAIL PROTECTED]> wrote: > My comments > > >groupId: org.apache.tuscany > >artifactId:das > > This is already taken by the DAS subproject > /java/das... > What do you think about something like : > > groupId: org.apache.tuscany.das > artifactId:das.api > artifactId:das.rdb > artifactId:das.ldap > > artifactId:distribution > artifactId:samples > > In the future, we might need to have samples moved > to each impl, so > das.rdbwould have it's own samples, and > das.ldap would have it's own samples. > > Toughts ? > > > On 1/31/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > > > I'm looking at creating the maven project for the > > das interfaces right now. > > > > I think > > groupId: org.apache.tuscany > > artifactId:das > > > > makes sense for the interfaces project. > > > > Then > > groupId: org.apache.tuscany > > artifactId:das.rdb > > artifactId:das.ldap > > > > for the datasource specific implementations. > > > > Thoughts? > > > > Thanks, > > - Ole > > > > --- Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > > Yes, this would be the first step and you are on > the > > > right track, if we > > > identify others, we could continue moving them > > > gradatively... > > > > > > Another think to have in mind, and I don't think > I > > > have an answer right now, > > > is around the config model, and where is the > best > > > place for it : API > > > project, a common impl project , or each > particular > > > backend impl. Probably > > > API, if the models don't defer much. > > > > > > Any Toughts ? > > > > > > -- > > > Luciano Resende > > > http://people.apache.org/~lresende > > > > > > On 1/30/07, Ole Ersoy <[EMAIL PROTECTED]> > wrote: > > > > > > > > OK - I think this is the trunk: > > > > > > > > > > > > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb > > > > > > > > And I think these are the interfaces: > > > > -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 > > > Command.java > > > > -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 > > > > ConfigHelper.java > > > > -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 > > > Converter.java > > > > -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 > > > DASFactory.java > > > > -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 > DAS.java > > > > -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 > Pager.java > > > > > > > > Am I on the righ track? If so, I'll move the > > > package > > > > containing the interfaces to another maven > project > > > and > > > > > > > > submit it via JIRA? > > > > > > > > Thanks, > > > > - Ole > > > > > > > > > > > > --- Luciano Resende <[EMAIL PROTECTED]> > wrote: > > > > > > > > > Trunk DAS is pretty stable, unless you find > any > > > > > problems with it, I'd > > > > > recommend staying with trunk. > > > > > > > > > > On 1/30/07, Ole Ersoy <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > Should I be grabbing das-java-M2? > > > > > > > > > > > > > > > > > > --- Luciano Resende <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > Yes, your CLA should be fine... > > > > > > > > > > > > > > One of the first things that we will > need on > > > DAS > > > > > to > > > > > > > easily accommodate new > > > > > > > implementations would be to refactor the > DAS > > > > > > > Interfaces to it's own project > > > > > > > (e.g DAS API) and have the current DAS > RDB > > > > > having > > > > > > > that as a dependency, and > > > > > > > then DAS LDAP would also use DAS API as > > > > > dependency. > > > > > > > > > > > > > > We would also need to enhance the API to > > > allow > > > > > > > instantiation of an specific > > > > > > > DAS impl. > > > > > > > > > > > > > > As for design topics, some of the things > > > that > > > > > come > > > > > > > to mind : > > > > > > > > > > > > > >- Command syntax > > > > > > > - mapping filters to ldap > searches > > > > > > > - is there a standard syntax > for > > > CRUD > > > > > > > operations in ldap ? > > > > > > >- Support for change summary > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Luciano Resende > > > > > > > http://people.apache.org/~lresende > > > > > > > > > > > > > > On 1/30/07, Ole Ersoy > <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > > > > > > > I have a CLA on file with the apache > > > directory > > > > > > > > project, so that probably applies for > > > Apache > > > > > in > > > > > > > > general right? > > > > > > > > > > > > > > > > OK - Cool - I'll gather up some of my > > > design > > > > > > > notes, go > > > > > > > > through the RDB DAS info, so I > understand > > > how > > > > > that > > > > > > > was > > > > > > > > done better, and try to come up with > > > something > > > > > > > inline > > > > > > > > with that for an LDAP DAS. If anyone > has > > > > > specific > > > > > > > > ideas I'll be glad to incorporate them > > > into > > > > > > > whatever > > > > > > > > design documentation produced. > > > > > > > > > > > > > > > > Cheers, > > > > > > > > - Ole > > > > > > > > > > > > > > >
[jira] Closed: (TUSCANY-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1084. -- Resolution: Fixed > Java Serialization: The Type definition is overwritten in the registry within > the same scope > > > Key: TUSCANY-1084 > URL: https://issues.apache.org/jira/browse/TUSCANY-1084 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > Fix For: Java-SDO-Mx > > Attachments: JavaSerializeDeserializeTestCase.java > > > When a DataObject is serialized using the java serialization ( > ObjectOutputStream.writeObject) and deserialized back using > ObjectInputStream.readObject, the types of the two dataobjects do not match, > even though this all in the same scope ( global in this case ). > During deserialization, it seems that the type of the dataobject cannot be > found, and it is creating the type again and simply overwrites the previously > registered type. This results in the dataobjects getting different types and > the test case fails. > There is another issue here, which is that currently there seems to be no way > to provide a scope when using these java serialization methods. For instance, > when using XMLHelper, you can get a scope defined XMLHelper. But how do you > do this when you are using the java serialization methods ? If you want me to > open another Jira for this i will. > Hasan -- 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-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1084: --- Fix Version/s: (was: Java-M2) Java-SDO-Mx > Java Serialization: The Type definition is overwritten in the registry within > the same scope > > > Key: TUSCANY-1084 > URL: https://issues.apache.org/jira/browse/TUSCANY-1084 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > Fix For: Java-SDO-Mx > > Attachments: JavaSerializeDeserializeTestCase.java > > > When a DataObject is serialized using the java serialization ( > ObjectOutputStream.writeObject) and deserialized back using > ObjectInputStream.readObject, the types of the two dataobjects do not match, > even though this all in the same scope ( global in this case ). > During deserialization, it seems that the type of the dataobject cannot be > found, and it is creating the type again and simply overwrites the previously > registered type. This results in the dataobjects getting different types and > the test case fails. > There is another issue here, which is that currently there seems to be no way > to provide a scope when using these java serialization methods. For instance, > when using XMLHelper, you can get a scope defined XMLHelper. But how do you > do this when you are using the java serialization methods ? If you want me to > open another Jira for this i will. > Hasan -- 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-1086) Scope defined java serialiazation/deserialization of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1086: --- Fix Version/s: Java-SDO-Mx > Scope defined java serialiazation/deserialization of SDO > > > Key: TUSCANY-1086 > URL: https://issues.apache.org/jira/browse/TUSCANY-1086 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > Fix For: Java-SDO-Mx > > > Need to have a scope defined java serialization/deserialization of SDO's. > Currently it can be done only in the Global/default scope. Have to fix this > by using helperContext as the scope for creating ObjectInputStream and > ObjectOutputStream. -- 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: LDAP DAS
My comments groupId: org.apache.tuscany artifactId:das This is already taken by the DAS subproject /java/das... What do you think about something like : groupId: org.apache.tuscany.das artifactId:das.api artifactId:das.rdb artifactId:das.ldap artifactId:distribution artifactId:samples In the future, we might need to have samples moved to each impl, so das.rdbwould have it's own samples, and das.ldap would have it's own samples. Toughts ? On 1/31/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: I'm looking at creating the maven project for the das interfaces right now. I think groupId: org.apache.tuscany artifactId:das makes sense for the interfaces project. Then groupId: org.apache.tuscany artifactId:das.rdb artifactId:das.ldap for the datasource specific implementations. Thoughts? Thanks, - Ole --- Luciano Resende <[EMAIL PROTECTED]> wrote: > Yes, this would be the first step and you are on the > right track, if we > identify others, we could continue moving them > gradatively... > > Another think to have in mind, and I don't think I > have an answer right now, > is around the config model, and where is the best > place for it : API > project, a common impl project , or each particular > backend impl. Probably > API, if the models don't defer much. > > Any Toughts ? > > -- > Luciano Resende > http://people.apache.org/~lresende > > On 1/30/07, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > > > OK - I think this is the trunk: > > > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/das/rdb > > > > And I think these are the interfaces: > > -rw-r--r-- 1 ole ole 1999 Sep 29 16:36 > Command.java > > -rw-r--r-- 1 ole ole 3914 Dec 4 14:40 > > ConfigHelper.java > > -rw-r--r-- 1 ole ole 2092 Oct 5 15:03 > Converter.java > > -rw-r--r-- 1 ole ole 2103 Oct 5 15:03 > DASFactory.java > > -rw-r--r-- 1 ole ole 2076 Sep 29 16:36 DAS.java > > -rw-r--r-- 1 ole ole 2154 Oct 5 15:03 Pager.java > > > > Am I on the righ track? If so, I'll move the > package > > containing the interfaces to another maven project > and > > > > submit it via JIRA? > > > > Thanks, > > - Ole > > > > > > --- Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > > Trunk DAS is pretty stable, unless you find any > > > problems with it, I'd > > > recommend staying with trunk. > > > > > > On 1/30/07, Ole Ersoy <[EMAIL PROTECTED]> > wrote: > > > > > > > > Should I be grabbing das-java-M2? > > > > > > > > > > > > --- Luciano Resende <[EMAIL PROTECTED]> > wrote: > > > > > > > > > Yes, your CLA should be fine... > > > > > > > > > > One of the first things that we will need on > DAS > > > to > > > > > easily accommodate new > > > > > implementations would be to refactor the DAS > > > > > Interfaces to it's own project > > > > > (e.g DAS API) and have the current DAS RDB > > > having > > > > > that as a dependency, and > > > > > then DAS LDAP would also use DAS API as > > > dependency. > > > > > > > > > > We would also need to enhance the API to > allow > > > > > instantiation of an specific > > > > > DAS impl. > > > > > > > > > > As for design topics, some of the things > that > > > come > > > > > to mind : > > > > > > > > > >- Command syntax > > > > > - mapping filters to ldap searches > > > > > - is there a standard syntax for > CRUD > > > > > operations in ldap ? > > > > >- Support for change summary > > > > > > > > > > > > > > > -- > > > > > Luciano Resende > > > > > http://people.apache.org/~lresende > > > > > > > > > > On 1/30/07, Ole Ersoy <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > I have a CLA on file with the apache > directory > > > > > > project, so that probably applies for > Apache > > > in > > > > > > general right? > > > > > > > > > > > > OK - Cool - I'll gather up some of my > design > > > > > notes, go > > > > > > through the RDB DAS info, so I understand > how > > > that > > > > > was > > > > > > done better, and try to come up with > something > > > > > inline > > > > > > with that for an LDAP DAS. If anyone has > > > specific > > > > > > ideas I'll be glad to incorporate them > into > > > > > whatever > > > > > > design documentation produced. > > > > > > > > > > > > Cheers, > > > > > > - Ole > > > > > > > > > > > > > > > > > > --- Luciano Resende <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > Probably starting some design > discussions on > > > the > > > > > > > dev-list, and later on > > > > > > > summarazing it on the wiki would be a > good > > > way > > > > > of > > > > > > > doing this. Not sure if > > > > > > > others have any more special handling > for > > > > > this... > > > > > > > > > > > > > > On the legal side, I think contributions > via > > > > > patches > > > > > > > should work just fine. > > > > > > > > > > > > > > On 1/29/07, Ole Ersoy > <[EMAIL PROTECTED]> > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Yes - Very much interested. > > > > > > > > > > > > > > > > We've been having discussions around > > > > > > > >
Re: [jira] Commented: (TUSCANY-925) Complex properties not supported
Hi,
The build is going through with r502344. Thanks.
- Venkat
*
*
On 2/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkat.
Thank you so much for staying late to fix the problem.
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 01, 2007 11:40 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I am in the process of fixing this and shall be done very
soon. Apologize
> to everybody for this mess up.
>
> - Venkat
>
> On 2/1/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I found two issues with the commit.
>>
>> 1) The "core" cannot be compiled at more. There's a class
>> "org.apache.tuscany.core.databinding.xml.Node2Object" still references
a
>> class that was deleted in your checkin.
>>
>> public class Node2Object extends XMLType2JavaTransformer {
>> ...
>> }
>>
>> 2) I'm not very sure if we should have a separate extension for the
>> JavaBeans databinding. Should we merge it into the core where we
already
>> have transformers dealing with XML parsing technologies.
>>
>> BTW, we also fix some checkstyle violations.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To:
>> Sent: Thursday, February 01, 2007 1:07 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I have committed a JavaBeans databinding and have refactored
somethings
>> > that
>> > were related to this that I had added to the SPI earlier. I shall
add
>> > more
>> > transformers in later increments, looking at the Axis2 link you have
>> > provided.
>> >
>> > Thanks
>> >
>> > - Venkat
>> >
>> > On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >>
>> >> Please see my comments inline.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> - Original Message -
>> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> To:
>> >> Sent: Tuesday, January 30, 2007 4:07 AM
>> >> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> >> supported
>> >>
>> >>
>> >> > Hi Raymond,
>> >> >
>> >> > I have done the following: -
>> >> >
>> >> > - Created a JavaBeansDataBinding with basetype as
>> >> > java.lang.Objectand
>> >> > have
>> >> > included a DOMNode2JavaBean transformer into this binding. This
>> >> > tranformer
>> >> > has the xml to javabean transformation that I have done.
>> >>
>> >> We probably need to add more transformers. Some code in the Axis2
ADB
>> >> might
>> >> help:
>> >>
>> >>
>>
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
>> >> .
>> >>
>> >> > - Extended the AbstractPropertyProcessor's method to look for
>> DataType
>> >> > annotations and then add the databinding name to the Property as
>> >> extension
>> >> > metadata.
>> >>
>> >> Yes.
>> >>
>> >> > - I have added the JavaBeansDataBinding and the DOMNode2JavaBean
>> >> > transformer
>> >> > as system components to databinding.scdl of core.
>> >> >
>> >> > Here are some queries that I have. Please help me with some
>> >> > clarity.
>> >> > 1) Now that we have the JavaBeansDataBinding, can we move the
>> >> Node2Object
>> >> > and Object2Node out of org.apache.tuscany.core.databinding.xml.
>> >> > Infact,
>> >> > Node2Object might get to be replaced by DOMNode2JavaBean. Also,
can
>> >> > the
>> >> > related type mappers such as SimpleTypeMapper be moved over into
>> >> > this
>> >> new
>> >> > databinding. This sort of consolidation seems to be inevitable
>> >> > since
>> >> only
>> >> > one of the transformers can stay registered with the runtime and
>> >> > that
>> >> will
>> >> > be the one that is registered last.
>> >>
>> >> I think we should consider the simple types as special cases of java
>> >> beans.
>> >> It makes sense to me that we unify them and use it as the default
>> >> databinding in the java world.
>> >>
>> >> >
>> >> > 2) Could you please help me understand the difference between
>> physical
>> >> and
>> >> > logical types in the DataType. Specifically in the context of
>> >> > implementations of DataBindings, I am getting the understanding
>> >> > that,
>> >> for
>> >> > a
>> >> > DataBinding to handle a specific DataType the physical type of the
>> >> > DataType
>> >> > must be compatible (say assignable) with the basetype of the
>> >> DataBinding.
>> >> > Is this understanding right?
>> >>
>> >> I think Jeremy has already explained this. Please see
>> >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13192.html.
>> >>
>> >> >
>> >> > If this is right, then I have an issue understanding the
>> implementation
>> >> of
>> >> > the 'introspect' method of the DataBindingExtension class. I have
>> >> > commented
>> >> > as "svkrish:" within the following snippet regarding my question.
>> >> >
>> >> > public DataType introspect(Class javaType) {
>> >> >if (baseType == n
Re: [jira] Commented: (TUSCANY-925) Complex properties not supported
Hi, Venkat.
Thank you so much for staying late to fix the problem.
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 01, 2007 11:40 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
Hi Raymond,
I am in the process of fixing this and shall be done very soon. Apologize
to everybody for this mess up.
- Venkat
On 2/1/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I found two issues with the commit.
1) The "core" cannot be compiled at more. There's a class
"org.apache.tuscany.core.databinding.xml.Node2Object" still references a
class that was deleted in your checkin.
public class Node2Object extends XMLType2JavaTransformer {
...
}
2) I'm not very sure if we should have a separate extension for the
JavaBeans databinding. Should we merge it into the core where we already
have transformers dealing with XML parsing technologies.
BTW, we also fix some checkstyle violations.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 01, 2007 1:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I have committed a JavaBeans databinding and have refactored somethings
> that
> were related to this that I had added to the SPI earlier. I shall add
> more
> transformers in later increments, looking at the Axis2 link you have
> provided.
>
> Thanks
>
> - Venkat
>
> On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To:
>> Sent: Tuesday, January 30, 2007 4:07 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I have done the following: -
>> >
>> > - Created a JavaBeansDataBinding with basetype as
>> > java.lang.Objectand
>> > have
>> > included a DOMNode2JavaBean transformer into this binding. This
>> > tranformer
>> > has the xml to javabean transformation that I have done.
>>
>> We probably need to add more transformers. Some code in the Axis2 ADB
>> might
>> help:
>>
>>
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
>> .
>>
>> > - Extended the AbstractPropertyProcessor's method to look for
DataType
>> > annotations and then add the databinding name to the Property as
>> extension
>> > metadata.
>>
>> Yes.
>>
>> > - I have added the JavaBeansDataBinding and the DOMNode2JavaBean
>> > transformer
>> > as system components to databinding.scdl of core.
>> >
>> > Here are some queries that I have. Please help me with some
>> > clarity.
>> > 1) Now that we have the JavaBeansDataBinding, can we move the
>> Node2Object
>> > and Object2Node out of org.apache.tuscany.core.databinding.xml.
>> > Infact,
>> > Node2Object might get to be replaced by DOMNode2JavaBean. Also, can
>> > the
>> > related type mappers such as SimpleTypeMapper be moved over into
>> > this
>> new
>> > databinding. This sort of consolidation seems to be inevitable
>> > since
>> only
>> > one of the transformers can stay registered with the runtime and
>> > that
>> will
>> > be the one that is registered last.
>>
>> I think we should consider the simple types as special cases of java
>> beans.
>> It makes sense to me that we unify them and use it as the default
>> databinding in the java world.
>>
>> >
>> > 2) Could you please help me understand the difference between
physical
>> and
>> > logical types in the DataType. Specifically in the context of
>> > implementations of DataBindings, I am getting the understanding
>> > that,
>> for
>> > a
>> > DataBinding to handle a specific DataType the physical type of the
>> > DataType
>> > must be compatible (say assignable) with the basetype of the
>> DataBinding.
>> > Is this understanding right?
>>
>> I think Jeremy has already explained this. Please see
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13192.html.
>>
>> >
>> > If this is right, then I have an issue understanding the
implementation
>> of
>> > the 'introspect' method of the DataBindingExtension class. I have
>> > commented
>> > as "svkrish:" within the following snippet regarding my question.
>> >
>> > public DataType introspect(Class javaType) {
>> >if (baseType == null || javaType == null) {
>> >return null;))
>> >}
>> >if (baseType.isAssignableFrom(javaType)) {
>> >//svkrish : should this not be...
>> > //...new DataType(name, baseType, javaType);
>> >return new DataType(name, javaType, baseType);
>> >} else {
>> >return null;
>> >}
>> >}
>> >
>> >
>> > Thanks for helping all the way :)
>> >
>> > - Venkat
>> >
>> >
>> > On 1/29/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >
[jira] Commented: (TUSCANY-1086) Scope defined java serialiazation/deserialization of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469563 ] Frank Budinsky commented on TUSCANY-1086: - Hasan, Thanks for doing this. I would say that we don't strictly need a scoped output stream, becasue the objects being serialized know their scope (types). It's only during deserialize (input stream) that we need to provide it with the location of the types. That said, I do think it would still be good to be symetrical and add two methods to SDOUtil: SDOUtil.createObjectInputStream(HelperContext scope); and SDOUtil.createObjectOutputStream(HelperContext scope); The second could just return an ordinary ObjectOutputStream. (maybe in the future it might do something special??). Frank. > Scope defined java serialiazation/deserialization of SDO > > > Key: TUSCANY-1086 > URL: https://issues.apache.org/jira/browse/TUSCANY-1086 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > > Need to have a scope defined java serialization/deserialization of SDO's. > Currently it can be done only in the Global/default scope. Have to fix this > by using helperContext as the scope for creating ObjectInputStream and > ObjectOutputStream. -- 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] Commented: (TUSCANY-925) Complex properties not supported
Hi Raymond,
I am in the process of fixing this and shall be done very soon. Apologize
to everybody for this mess up.
- Venkat
On 2/1/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
I found two issues with the commit.
1) The "core" cannot be compiled at more. There's a class
"org.apache.tuscany.core.databinding.xml.Node2Object" still references a
class that was deleted in your checkin.
public class Node2Object extends XMLType2JavaTransformer {
...
}
2) I'm not very sure if we should have a separate extension for the
JavaBeans databinding. Should we merge it into the core where we already
have transformers dealing with XML parsing technologies.
BTW, we also fix some checkstyle violations.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 01, 2007 1:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I have committed a JavaBeans databinding and have refactored somethings
> that
> were related to this that I had added to the SPI earlier. I shall add
> more
> transformers in later increments, looking at the Axis2 link you have
> provided.
>
> Thanks
>
> - Venkat
>
> On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To:
>> Sent: Tuesday, January 30, 2007 4:07 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I have done the following: -
>> >
>> > - Created a JavaBeansDataBinding with basetype as java.lang.Objectand
>> > have
>> > included a DOMNode2JavaBean transformer into this binding. This
>> > tranformer
>> > has the xml to javabean transformation that I have done.
>>
>> We probably need to add more transformers. Some code in the Axis2 ADB
>> might
>> help:
>>
>>
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
>> .
>>
>> > - Extended the AbstractPropertyProcessor's method to look for
DataType
>> > annotations and then add the databinding name to the Property as
>> extension
>> > metadata.
>>
>> Yes.
>>
>> > - I have added the JavaBeansDataBinding and the DOMNode2JavaBean
>> > transformer
>> > as system components to databinding.scdl of core.
>> >
>> > Here are some queries that I have. Please help me with some clarity.
>> > 1) Now that we have the JavaBeansDataBinding, can we move the
>> Node2Object
>> > and Object2Node out of org.apache.tuscany.core.databinding.xml.
>> > Infact,
>> > Node2Object might get to be replaced by DOMNode2JavaBean. Also, can
>> > the
>> > related type mappers such as SimpleTypeMapper be moved over into this
>> new
>> > databinding. This sort of consolidation seems to be inevitable since
>> only
>> > one of the transformers can stay registered with the runtime and that
>> will
>> > be the one that is registered last.
>>
>> I think we should consider the simple types as special cases of java
>> beans.
>> It makes sense to me that we unify them and use it as the default
>> databinding in the java world.
>>
>> >
>> > 2) Could you please help me understand the difference between
physical
>> and
>> > logical types in the DataType. Specifically in the context of
>> > implementations of DataBindings, I am getting the understanding that,
>> for
>> > a
>> > DataBinding to handle a specific DataType the physical type of the
>> > DataType
>> > must be compatible (say assignable) with the basetype of the
>> DataBinding.
>> > Is this understanding right?
>>
>> I think Jeremy has already explained this. Please see
>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13192.html.
>>
>> >
>> > If this is right, then I have an issue understanding the
implementation
>> of
>> > the 'introspect' method of the DataBindingExtension class. I have
>> > commented
>> > as "svkrish:" within the following snippet regarding my question.
>> >
>> > public DataType introspect(Class javaType) {
>> >if (baseType == null || javaType == null) {
>> >return null;))
>> >}
>> >if (baseType.isAssignableFrom(javaType)) {
>> >//svkrish : should this not be...
>> > //...new DataType(name, baseType, javaType);
>> >return new DataType(name, javaType, baseType);
>> >} else {
>> >return null;
>> >}
>> >}
>> >
>> >
>> > Thanks for helping all the way :)
>> >
>> > - Venkat
>> >
>> >
>> > On 1/29/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >>
>> >> Please see my comments below.
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> - Original Message -
>> >> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> >> To:
>> >> Sent: Monday, January 29, 2007 12:36 AM
>> >> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> >> supported
>> >>
>> >>
>> >
Re: [SDO Java] thoughts on generating classes from in memory models
Kelvin,
The generator is not supposed to generate anything for the document root.
It's prevented by this code in class JavaGenerator:
if ("DocumentRoot".equals(genClass.getName()))
{
genClass.setDynamic(true); // Don't generate DocumentRoot class
break;
}
This tells the generator that the document root should be handled as a
dynamic DataObject.
So, you could probably fix this by adding a check for null as well in
JavaGenerator, but it may be better to instead change TypeHelper to also
use "DocumentRoot" as the name. The name is really not relevant in the RT
implementation. It's the xml name, ExtendedMetaData.getName(), of "" that
is used to identify a document root.
Frank.
"kelvin goodson" <[EMAIL PROTECTED]> wrote on 02/01/2007 12:04:23
PM:
> I'm currently trying to generate SDO classes exhibiting multiple
inheritance
> to test that the generator is doing the right thing in the presence of
such
> models. I can't describe these with an XSD, so I am building up the
models
> with DataObjects, submitting them to TypeHelper.define() and then
pinching
> code from the XSD2JavaGenerator to finish the job. However, there's a
> difference between the way TypeHelper.define and XSDHelper.define handle
> global elements, which is blocking me. XSDHelper puts its global
elements
> by default in a type called "DocumentRoot" but TypeHelper uses the new
open
> content property creation scheme and puts these properties in a type
with a
> null value for its name. The EMF generator doesn't like this and falls
over
> thus ...
>
> Exception in thread "main" java.lang.NullPointerException
> at
org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.isEObject(
> GenClassImpl.java:831)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.
> GenPackageImpl$SwitchHelper.initLocal
> (GenPackageImpl.java:2233)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper
> .(GenPackageImpl.java:2215)
> at
> org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.prepareCache(
> GenPackageImpl.java:2703)
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.
> GenPackageGeneratorAdapter.doPreGenerate
> (GenPackageGeneratorAdapter.java:136)
> at
>
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate
> (AbstractGeneratorAdapter.java:157)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
> Generator.java:327)
> at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
> Generator.java:296)
> at
org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel(
> JavaGenerator.java:448)
> at org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(
> JavaGenerator.java:370)
> at
>
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeDesc
> (MemoryModel2JavaGenerator.java:133)
> at
>
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeList
> (MemoryModel2JavaGenerator.java:113)
> at
org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.run(
> GenMultipleInheritanceTestClasses.java:31)
> at
org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.main(
> GenMultipleInheritanceTestClasses.java:56)
>
> So I'm trying to figure out what my options are, and whether I need to
seek
> a fix in EMF, or find a way round this in our implementation. Any
thoughts?
>
> Regards, Kelvin.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1087) DAS should not commit individual commands as part of applyChanges
DAS should not commit individual commands as part of applyChanges - Key: TUSCANY-1087 URL: https://issues.apache.org/jira/browse/TUSCANY-1087 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Mx Reporter: Kevin Williams Fix For: Java-DAS-Mx The DAS must commit all commands resulting from ChangeSummary processing as an atomic unit. Sam Su's original note: "Hi kevin, thanks for you response. I debuged the application in Eclipse, I was sure that after user1 was inserted into database without an exception, a commit was performed on the connection. as two data objects needed to be inserted into database in my program, from the DAS source code, DAS will produce two different InsertCommandImpl instances for these two changes.The 'success' flag is in two different command instance, furthermore, it's a method scope variable, it can not be shared between two command instances. When command instance for user1 execute without an exception, it will proceed to perform a commit on the connection, command instance for user2 execute will throw an exception, so rollback. However the use1 has been already commited to database although use2 fail to be inserted into database." I have added a test "TransactionTests.estReadModifyApply()" t hat demonstrates this defect. -- 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: [SDO Java] thoughts on generating classes from in memory models
I see TypeHelperImpl#defineOpenContentProperty creates(SDOUtil.createType)
DocumentRoot if not existed.
SDOUtil.createType creates DocumentRoot by DataObjectUtil.createDocumentRoot
().
DataObjectUtil.createDocumentRoot() has set XML name ("") while forgetting
eCore name ("DocumentRoot" normally).
It can be fixed by
documentRootEClass.setName("DocumentRoot");
On 2/1/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
I'm currently trying to generate SDO classes exhibiting multiple
inheritance
to test that the generator is doing the right thing in the presence of
such
models. I can't describe these with an XSD, so I am building up the
models
with DataObjects, submitting them to TypeHelper.define() and then pinching
code from the XSD2JavaGenerator to finish the job. However, there's a
difference between the way TypeHelper.define and XSDHelper.define handle
global elements, which is blocking me. XSDHelper puts its global
elements
by default in a type called "DocumentRoot" but TypeHelper uses the new
open
content property creation scheme and puts these properties in a type with
a
null value for its name. The EMF generator doesn't like this and falls
over
thus ...
Exception in thread "main" java.lang.NullPointerException
at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.isEObject(
GenClassImpl.java:831)
at
org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper.initLocal
(GenPackageImpl.java:2233)
at
org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper
.(GenPackageImpl.java:2215)
at
org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.prepareCache(
GenPackageImpl.java:2703)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.doPreGenerate
(GenPackageGeneratorAdapter.java:136)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate
(AbstractGeneratorAdapter.java:157)
at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
Generator.java:327)
at org.eclipse.emf.codegen.ecore.generator.Generator.generate(
Generator.java:296)
at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel(
JavaGenerator.java:448)
at org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages(
JavaGenerator.java:370)
at
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeDesc
(MemoryModel2JavaGenerator.java:133)
at
org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeList
(MemoryModel2JavaGenerator.java:113)
at org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.run(
GenMultipleInheritanceTestClasses.java:31)
at org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.main(
GenMultipleInheritanceTestClasses.java:56)
So I'm trying to figure out what my options are, and whether I need to
seek
a fix in EMF, or find a way round this in our implementation. Any
thoughts?
Regards, Kelvin.
--
Yang ZHONG
Re: Moving modules around in trunk
On Feb 1, 2007, at 1:26 AM, ant elder wrote: I think we could still do more. For example how about any of: - Move cts into testing - Delete distribution (distribution/sca/standalone and webapp are obsolete now right?) - Merge sampleapps into samples - Move the sca specific samples from samples to sca/samples - inner.composite, echo.binding etc. - Does java/sca/doc really need to be here, could these be moved to the website/wiki? - Do something with java/sca/plugins/itest.plugin and test, maybe sca/testing/junit and sca/testing/itest - Move all the java/sca/services/databindings to sca/extensions like the axiom one, (and databinding/test to sca/testing?) ...ant +1 sounds good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-925) Complex properties not supported
Hi,
I found two issues with the commit.
1) The "core" cannot be compiled at more. There's a class
"org.apache.tuscany.core.databinding.xml.Node2Object" still references a
class that was deleted in your checkin.
public class Node2Object extends XMLType2JavaTransformer {
...
}
2) I'm not very sure if we should have a separate extension for the
JavaBeans databinding. Should we merge it into the core where we already
have transformers dealing with XML parsing technologies.
BTW, we also fix some checkstyle violations.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Thursday, February 01, 2007 1:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
Hi Raymond,
I have committed a JavaBeans databinding and have refactored somethings
that
were related to this that I had added to the SPI earlier. I shall add
more
transformers in later increments, looking at the Axis2 link you have
provided.
Thanks
- Venkat
On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkat.
Please see my comments inline.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, January 30, 2007 4:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I have done the following: -
>
> - Created a JavaBeansDataBinding with basetype as java.lang.Object and
> have
> included a DOMNode2JavaBean transformer into this binding. This
> tranformer
> has the xml to javabean transformation that I have done.
We probably need to add more transformers. Some code in the Axis2 ADB
might
help:
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
.
> - Extended the AbstractPropertyProcessor's method to look for DataType
> annotations and then add the databinding name to the Property as
extension
> metadata.
Yes.
> - I have added the JavaBeansDataBinding and the DOMNode2JavaBean
> transformer
> as system components to databinding.scdl of core.
>
> Here are some queries that I have. Please help me with some clarity.
> 1) Now that we have the JavaBeansDataBinding, can we move the
Node2Object
> and Object2Node out of org.apache.tuscany.core.databinding.xml.
> Infact,
> Node2Object might get to be replaced by DOMNode2JavaBean. Also, can
> the
> related type mappers such as SimpleTypeMapper be moved over into this
new
> databinding. This sort of consolidation seems to be inevitable since
only
> one of the transformers can stay registered with the runtime and that
will
> be the one that is registered last.
I think we should consider the simple types as special cases of java
beans.
It makes sense to me that we unify them and use it as the default
databinding in the java world.
>
> 2) Could you please help me understand the difference between physical
and
> logical types in the DataType. Specifically in the context of
> implementations of DataBindings, I am getting the understanding that,
for
> a
> DataBinding to handle a specific DataType the physical type of the
> DataType
> must be compatible (say assignable) with the basetype of the
DataBinding.
> Is this understanding right?
I think Jeremy has already explained this. Please see
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13192.html.
>
> If this is right, then I have an issue understanding the implementation
of
> the 'introspect' method of the DataBindingExtension class. I have
> commented
> as "svkrish:" within the following snippet regarding my question.
>
> public DataType introspect(Class javaType) {
>if (baseType == null || javaType == null) {
>return null;))
>}
>if (baseType.isAssignableFrom(javaType)) {
>//svkrish : should this not be...
> //...new DataType(name, baseType, javaType);
>return new DataType(name, javaType, baseType);
>} else {
>return null;
>}
>}
>
>
> Thanks for helping all the way :)
>
> - Venkat
>
>
> On 1/29/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> Please see my comments below.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To:
>> Sent: Monday, January 29, 2007 12:36 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I looked up the current implementation and have some queries
regarding
>> > your
>> > suggestions. Please help me with some clarifications inline.
>> > Thanks
>> >
>> > - Venkat
>> >
>> >
>> > On 1/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >>
>> >> I think we should reorganize the code to match what we envisioned
>> before.
>> >> Here's the basic idea:
>> >>
>> >> 1) The property values are loaded as DOM objects by the runtime
during
>> >> the
>> >> loading phase
>> >
>> >
>> > T
[SDO Java] thoughts on generating classes from in memory models
I'm currently trying to generate SDO classes exhibiting multiple inheritance to test that the generator is doing the right thing in the presence of such models. I can't describe these with an XSD, so I am building up the models with DataObjects, submitting them to TypeHelper.define() and then pinching code from the XSD2JavaGenerator to finish the job. However, there's a difference between the way TypeHelper.define and XSDHelper.define handle global elements, which is blocking me. XSDHelper puts its global elements by default in a type called "DocumentRoot" but TypeHelper uses the new open content property creation scheme and puts these properties in a type with a null value for its name. The EMF generator doesn't like this and falls over thus ... Exception in thread "main" java.lang.NullPointerException at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.isEObject( GenClassImpl.java:831) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper.initLocal (GenPackageImpl.java:2233) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$SwitchHelper .(GenPackageImpl.java:2215) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.prepareCache( GenPackageImpl.java:2703) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.doPreGenerate (GenPackageGeneratorAdapter.java:136) at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate (AbstractGeneratorAdapter.java:157) at org.eclipse.emf.codegen.ecore.generator.Generator.generate( Generator.java:327) at org.eclipse.emf.codegen.ecore.generator.Generator.generate( Generator.java:296) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel( JavaGenerator.java:448) at org.apache.tuscany.sdo.generate.JavaGenerator.generatePackages( JavaGenerator.java:370) at org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeDesc (MemoryModel2JavaGenerator.java:133) at org.apache.tuscany.sdo.generate.MemoryModel2JavaGenerator.generateFromTypeList (MemoryModel2JavaGenerator.java:113) at org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.run( GenMultipleInheritanceTestClasses.java:31) at org.apache.tuscany.sdo.test.GenMultipleInheritanceTestClasses.main( GenMultipleInheritanceTestClasses.java:56) So I'm trying to figure out what my options are, and whether I need to seek a fix in EMF, or find a way round this in our implementation. Any thoughts? Regards, Kelvin.
Re: Moving modules around in trunk
Sounds good. On the testing front, I think the itest plugin should move under runtime as it's really another runtime that happens to run in a Maven environment. I'm happy to take care of that. CurrentCompositeContext is going to be removed from the API spec so we'll need an alternative. I think this will allow us to simplify testing from an IDE environment and get rid of SCATestCase - I'll say more in another thread. These changes should allow us to get rid of the test module completely. -- Jeremy On Feb 1, 2007, at 1:26 AM, ant elder wrote: I think we could still do more. For example how about any of: - Move cts into testing - Delete distribution (distribution/sca/standalone and webapp are obsolete now right?) - Merge sampleapps into samples - Move the sca specific samples from samples to sca/samples - inner.composite, echo.binding etc. - Does java/sca/doc really need to be here, could these be moved to the website/wiki? - Do something with java/sca/plugins/itest.plugin and test, maybe sca/testing/junit and sca/testing/itest - Move all the java/sca/services/databindings to sca/extensions like the axiom one, (and databinding/test to sca/testing?) ...ant On 1/31/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I was watching what you were doing with axsi2 etc. I think you've done everything that I planned. Thanks for picking it up. -- Jeremy On Jan 31, 2007, at 7:08 AM, ant elder wrote: > Are you still planning on do anything like this? I would help but > its not > clear to me what you want to move where? > > ...ant > > On 1/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> Rick pinged me tonight about problems building from the sca >> directory. It turns out modules that build on their own can fail if >> run as part of a reactor run as mvn gets confused over whether it >> should be using the pre-spec tree or trunk. >> >> Unless someone beats me to it, I intend to fix that tomorrow by >> moving some of the modules around so there is a clear distinction >> between kernel, runtime and runtime services, and extensions. The >> first two will be the same modules currently in pre-spec and the >> extensions will depend on those (so its easy for an extension to >> choose if it depends on trunk or pre-spec). >> >> -- >> Jeremy >> >> >> - >> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Board report due this month
The page is here: http://wiki.apache.org/incubator/February2007 I'm happy to pull together comments if people send them here - or just update the page :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1086) Scope defined java serialiazation/deserialization of SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469427 ] Hasan Muhammad commented on TUSCANY-1086: - Frank, Would you want the same for an ObjectOutputStream (i.e. scope defined ) ? I was wondering why would anyone want to have a scope on both, since if at all one wanted to use the same scope for serialization/deserializaton, then they would use the global scope.. But still, wanted to ask if you thought we needed a scope defined ObjectOutputStream as well ? BTW, i am creating a new class called SDOObjectInputStream under org.apache.tuscany.sdo.util.resource, just a placeHolder for the scope. This would be returned by the create method. Hasan > Scope defined java serialiazation/deserialization of SDO > > > Key: TUSCANY-1086 > URL: https://issues.apache.org/jira/browse/TUSCANY-1086 > Project: Tuscany > Issue Type: Improvement > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > > Need to have a scope defined java serialization/deserialization of SDO's. > Currently it can be done only in the Global/default scope. Have to fix this > by using helperContext as the scope for creating ObjectInputStream and > ObjectOutputStream. -- 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-1084) Java Serialization: The Type definition is overwritten in the registry within the same scope
[ https://issues.apache.org/jira/browse/TUSCANY-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469424 ] Hasan Muhammad commented on TUSCANY-1084: - Ok. Opened Tuscany-1086 for this limitation. Will close this one > Java Serialization: The Type definition is overwritten in the registry within > the same scope > > > Key: TUSCANY-1084 > URL: https://issues.apache.org/jira/browse/TUSCANY-1084 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: All >Reporter: Hasan Muhammad > Fix For: Java-M2 > > Attachments: JavaSerializeDeserializeTestCase.java > > > When a DataObject is serialized using the java serialization ( > ObjectOutputStream.writeObject) and deserialized back using > ObjectInputStream.readObject, the types of the two dataobjects do not match, > even though this all in the same scope ( global in this case ). > During deserialization, it seems that the type of the dataobject cannot be > found, and it is creating the type again and simply overwrites the previously > registered type. This results in the dataobjects getting different types and > the test case fails. > There is another issue here, which is that currently there seems to be no way > to provide a scope when using these java serialization methods. For instance, > when using XMLHelper, you can get a scope defined XMLHelper. But how do you > do this when you are using the java serialization methods ? If you want me to > open another Jira for this i will. > Hasan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1086) Scope defined java serialiazation/deserialization of SDO
Scope defined java serialiazation/deserialization of SDO Key: TUSCANY-1086 URL: https://issues.apache.org/jira/browse/TUSCANY-1086 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-M2 Environment: All Reporter: Hasan Muhammad Need to have a scope defined java serialization/deserialization of SDO's. Currently it can be done only in the Global/default scope. Have to fix this by using helperContext as the scope for creating ObjectInputStream and ObjectOutputStream. -- 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: Moving modules around in trunk
Hi Ant, First thanks for doing this. Wherther or not for the other cases, I very strongly feel we must merge the samples and sampleapps as its quite confusing to new comers. - Venkat On 2/1/07, ant elder <[EMAIL PROTECTED]> wrote: I think we could still do more. For example how about any of: - Move cts into testing - Delete distribution (distribution/sca/standalone and webapp are obsolete now right?) - Merge sampleapps into samples - Move the sca specific samples from samples to sca/samples - inner.composite, echo.binding etc. - Does java/sca/doc really need to be here, could these be moved to the website/wiki? - Do something with java/sca/plugins/itest.plugin and test, maybe sca/testing/junit and sca/testing/itest - Move all the java/sca/services/databindings to sca/extensions like the axiom one, (and databinding/test to sca/testing?) ...ant On 1/31/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > I was watching what you were doing with axsi2 etc. I think you've > done everything that I planned. Thanks for picking it up. > -- > Jeremy > > On Jan 31, 2007, at 7:08 AM, ant elder wrote: > > > Are you still planning on do anything like this? I would help but > > its not > > clear to me what you want to move where? > > > > ...ant > > > > On 1/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > >> > >> Rick pinged me tonight about problems building from the sca > >> directory. It turns out modules that build on their own can fail if > >> run as part of a reactor run as mvn gets confused over whether it > >> should be using the pre-spec tree or trunk. > >> > >> Unless someone beats me to it, I intend to fix that tomorrow by > >> moving some of the modules around so there is a clear distinction > >> between kernel, runtime and runtime services, and extensions. The > >> first two will be the same modules currently in pre-spec and the > >> extensions will depend on those (so its easy for an extension to > >> choose if it depends on trunk or pre-spec). > >> > >> -- > >> Jeremy > >> > >> > >> - > >> 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] Resolved: (TUSCANY-1062) DataGraph.createRootObject implementation does not match 2.1 spec and also is not helpful when given bad parameters
[ https://issues.apache.org/jira/browse/TUSCANY-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1062. - Resolution: Fixed Applied patch, thanks. > DataGraph.createRootObject implementation does not match 2.1 spec and also is > not helpful when given bad parameters > --- > > Key: TUSCANY-1062 > URL: https://issues.apache.org/jira/browse/TUSCANY-1062 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 >Reporter: Paul Golick > Fix For: Java-SDO-Mx > > Attachments: DataGraphImpl_patch.txt, DataGraphTestCase.jar > > > When createRootObject is called and a root object has already been created, > the SDO 2.1 spec calls for an IllegalStateException but the current > implementation replaces the existing root. > Also, when either a type is not provided or when a type cannot be determined > from the URI and typeName provided, a NullPointerException is thrown from > org.eclipse.emf.ecore.util.EcoreUtil.create() which is not helpful to a user > who is not literate in emf utilities: an exception with a helpful error > message should be provided. > Attached are: > a) a jar containing a new test case file for DataGraph > (sdo/impl/src/test/java/org/apache/tuscany/sdo/test/DataGraphTestCase.java) > b) a patch that corrects these problems in > sdo/impl/src/main/java/org/apache/tuscany/sdo/impl/DataGraphImpl.java -- 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]
Federated assembly -> Work so far
Hi, I have been working on the stuff around federated assembly and enabling distributed SCA domains. Here is a quick summary of what has been done so far, Work in progress * Discovery Service * Provides the low-level communication abstraction for enabling runtimes participating in the domain to exchange information * The abstraction supports directed message delivery to a given runtime, asynchronous message reception and broadcast to all runtimes participating in the domain * To start with we are following a model, where one runtime in the domain assumes the master role and is responsible for managing the logical assembly * This runtime creates the physical artifacts and trensport them to the target slave runtimes * The discovery abstraction is defined in SPI * There are two implementations in runtime/services - JXTA and Bonjour * JXTA implementaion is getting pretty much there, it mainly uses the JXTA Peer Discovery protocol (PDP) and Peer Resolver Protocol (PRP) * Marshalling Framework * This is similar to our loader framework, however supports bi-directional marshalling and unmarshalling of physical model objects * This framework is used by the assembly service to serialize and transport physical model information to slave runtimes using the discovery services * On the receiving end the serialized information is unmarshalled by the federated deployer for being applied to the slave runtime * The abstraction is defined in SPI * I am working on an implementation in core * The framework supports versioning of physicla model objects if the participating runtimes are at different versions * Federated Deployer * This is similar to the local deployer, however registers itself with the discovery service for receiving physical model updates * The federated deployer doesn't use the loader framework * The federated deployer accepts serialized physical model information in XML, rather than raw SCDL as with local deployer * It uses the current builder framework to build, prepare and start the components Work outstanding * Define the physical model in Java * Define the corresponding XML infoset Some of this is related to the contribution and assembly service which Jeremy is working on. I assume the assembly service will be the main consumer to the discovery service and marshalling framework on the master side. On the slave side, the federated deployer will be registered with the discovery service for receiving asynchronous model updates from the master. Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs.
Re: Moving modules around in trunk
I think we could still do more. For example how about any of: - Move cts into testing - Delete distribution (distribution/sca/standalone and webapp are obsolete now right?) - Merge sampleapps into samples - Move the sca specific samples from samples to sca/samples - inner.composite, echo.binding etc. - Does java/sca/doc really need to be here, could these be moved to the website/wiki? - Do something with java/sca/plugins/itest.plugin and test, maybe sca/testing/junit and sca/testing/itest - Move all the java/sca/services/databindings to sca/extensions like the axiom one, (and databinding/test to sca/testing?) ...ant On 1/31/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: I was watching what you were doing with axsi2 etc. I think you've done everything that I planned. Thanks for picking it up. -- Jeremy On Jan 31, 2007, at 7:08 AM, ant elder wrote: > Are you still planning on do anything like this? I would help but > its not > clear to me what you want to move where? > > ...ant > > On 1/27/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> Rick pinged me tonight about problems building from the sca >> directory. It turns out modules that build on their own can fail if >> run as part of a reactor run as mvn gets confused over whether it >> should be using the pre-spec tree or trunk. >> >> Unless someone beats me to it, I intend to fix that tomorrow by >> moving some of the modules around so there is a clear distinction >> between kernel, runtime and runtime services, and extensions. The >> first two will be the same modules currently in pre-spec and the >> extensions will depend on those (so its easy for an extension to >> choose if it depends on trunk or pre-spec). >> >> -- >> Jeremy >> >> >> - >> 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] Commented: (TUSCANY-925) Complex properties not supported
Hi Raymond,
I have committed a JavaBeans databinding and have refactored somethings that
were related to this that I had added to the SPI earlier. I shall add more
transformers in later increments, looking at the Axis2 link you have
provided.
Thanks
- Venkat
On 1/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Venkat.
Please see my comments inline.
Thanks,
Raymond
- Original Message -
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, January 30, 2007 4:07 AM
Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
supported
> Hi Raymond,
>
> I have done the following: -
>
> - Created a JavaBeansDataBinding with basetype as java.lang.Object and
> have
> included a DOMNode2JavaBean transformer into this binding. This
> tranformer
> has the xml to javabean transformation that I have done.
We probably need to add more transformers. Some code in the Axis2 ADB
might
help:
http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/src/org/apache/axis2/databinding/utils/
.
> - Extended the AbstractPropertyProcessor's method to look for DataType
> annotations and then add the databinding name to the Property as
extension
> metadata.
Yes.
> - I have added the JavaBeansDataBinding and the DOMNode2JavaBean
> transformer
> as system components to databinding.scdl of core.
>
> Here are some queries that I have. Please help me with some clarity.
> 1) Now that we have the JavaBeansDataBinding, can we move the
Node2Object
> and Object2Node out of org.apache.tuscany.core.databinding.xml. Infact,
> Node2Object might get to be replaced by DOMNode2JavaBean. Also, can the
> related type mappers such as SimpleTypeMapper be moved over into this
new
> databinding. This sort of consolidation seems to be inevitable since
only
> one of the transformers can stay registered with the runtime and that
will
> be the one that is registered last.
I think we should consider the simple types as special cases of java
beans.
It makes sense to me that we unify them and use it as the default
databinding in the java world.
>
> 2) Could you please help me understand the difference between physical
and
> logical types in the DataType. Specifically in the context of
> implementations of DataBindings, I am getting the understanding that,
for
> a
> DataBinding to handle a specific DataType the physical type of the
> DataType
> must be compatible (say assignable) with the basetype of the
DataBinding.
> Is this understanding right?
I think Jeremy has already explained this. Please see
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13192.html.
>
> If this is right, then I have an issue understanding the implementation
of
> the 'introspect' method of the DataBindingExtension class. I have
> commented
> as "svkrish:" within the following snippet regarding my question.
>
> public DataType introspect(Class javaType) {
>if (baseType == null || javaType == null) {
>return null;))
>}
>if (baseType.isAssignableFrom(javaType)) {
>//svkrish : should this not be...
> //...new DataType(name, baseType, javaType);
>return new DataType(name, javaType, baseType);
>} else {
>return null;
>}
>}
>
>
> Thanks for helping all the way :)
>
> - Venkat
>
>
> On 1/29/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>>
>> Hi, Venkat.
>>
>> Please see my comments below.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message -
>> From: "Venkata Krishnan" <[EMAIL PROTECTED]>
>> To:
>> Sent: Monday, January 29, 2007 12:36 AM
>> Subject: Re: [jira] Commented: (TUSCANY-925) Complex properties not
>> supported
>>
>>
>> > Hi Raymond,
>> >
>> > I looked up the current implementation and have some queries
regarding
>> > your
>> > suggestions. Please help me with some clarifications inline. Thanks
>> >
>> > - Venkat
>> >
>> >
>> > On 1/26/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hi, Venkat.
>> >>
>> >> I think we should reorganize the code to match what we envisioned
>> before.
>> >> Here's the basic idea:
>> >>
>> >> 1) The property values are loaded as DOM objects by the runtime
during
>> >> the
>> >> loading phase
>> >
>> >
>> > This is already in place, isn't it?
>>
>> Yes, we already have this feature.
>>
>> >
>> > 2) The component implementations express their requirements for the
>> > property
>> >> values using DataType. For java component, this can be achieved by
>> >> annotating the property with @DataType. This becomes extensions to
the
>> >> componentType.
>> >>
>> > 3) The property injector will transform the property value from DOM
to
>> the
>> >> target data type (for example, SDO, JAXB, JavaBeans, etc).
>> >
>> >
>> > I understand these two and I guess you have already put things in
place
>> to
>> > some extent in PropertyObjectFactoryImpl.ObjectFactoryImplclass. Just
>> > that
>> > I have now enabled the target databinding to be picked up from the
>> > annotations.
>>
>
Re: [C++] Interface descriptions and type conversions
On 2/1/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Simon Laws wrote: > I notice in implementing the PHP extension (yes - believe it or not I'm > nearly ready to make a patch for the next version ;-) that, given the way > that I have implemented the PHP extension there is insufficient > information > available in the SCA runtime in order to do correct type conversions when > passing messages between components. I imagine this has been raised > before > but I looked at the archive and couldn't find a relevant thread. > > Imagine the scenario: > > C++ Component (ComponentA) ---WireA---> PHP Component (ComponentB) > ---WireB> C++ Component (ComponentC) > > Currently the build process looks at the header files described in the > component type files and generates wrappers and proxies for the C++ > components. I have currently implemented the PHP Extension to use generic > wrappers and proxies, i.e. it doesn't use those generated based on the > interface descriptions, so they need to dynamically manage the type > conversions for data coming in and going out of a PHP component. > > WireA. > > This is OK because the C++ SCA operation object that appears at > Component B > has a set of data/types based on the generated proxy. The PHP > extension can > look at this and effect the right type conversions. > > WireB > > This is problematic. The dynamic PHP proxy has to generate an operation > object to pass to the the wrapper of ComponentC. The issue is that > there is, > as far as I can tell, no dynamic way of getting at the list of types that > are expected for any particular operation. There is of course a static > C++ > proxy/wrapper combination that has been generated but I can't inspect > it at > runtime. > > I'm not keen on generating PHP specific interface classes. PHP is a > dynamic > environment and it's a whole stack of extra files we could do without > having > to manage particularly if we have to adapt the generator for every > extension > that's constructed. Can we extend the wrapper/proxy mechanism to > encapsulate > a runtime list of required types alongside the static method descriptions > that are already generated? We would need this to work for script to > script > calls as well as for the script/C++ combination so maybe we need > something > that hangs off the interface description part of the model. I'm not that > familiar with how that part of the model is used so a little > investigation > is required. > > Thoughts? > > Simon > Simon, It's an interesting issue. To explore it let's walk through the wiring scenario you describe and assume the following: - ComponentA (C++) -> WireA -> ComponentB (PHP) -> WireB -> ComponentC (C++) - ComponentA (C++) passes a short int to ComponentB (PHP) - ComponentB executes a PHP script which in turn passes a number to ComponentC (C++) - ComponentC expects that number to be given as a long int. Here's what I think should happen in the runtime: 1. At the source of WireA, a generated C++ CPPServiceProxy adds to our Operation object a Parameter of a type decided by the C++ client code: a C++ short int, with type == ParameterType::SHORT. 2. At the end of WireA, a PHPServiceWrapper converts that parameter to what the PHP script expects, for the sake of simplicity now I am going to assume that it needs to convert it to a C++ std::string. 3. The PHP script executes, now passes an std::string containing a number to the PHPServiceProxy at the source of WireB. 4. The PHPServiceProxy does not have much type info about that std::string parameter and can only add it to the Operation object as a std::string with type == ParameterType::STRING. 5. The CPPServiceWrapper at the end of WireB (actually the C++ ServiceWrapper generated for ComponentC) receives the std::string and should convert it to what ComponentC expects: a long int. The general idea is that a ServiceProxy sends what it is given (or picks the most natural type out of the ParameterTypes that we have defined and converts the data to it). A ServiceWrapper converts what it receives to the type expected by the code it wraps. I think that the CPPServiceWrapper code and the generated C++ ServiceWrappers are simply missing the logic to convert data to what the target expects. At the moment this limitation also prevents a C++ method getCustomer(long customerID) to be exposed as a REST service for example, as the generated C++ ServiceWrapper is missing the logic to convert the customerID received in string form from the REST query string to the expected C++ long int. So we just need to add the missing type conversion logic to the C++ ServiceWrappers :) Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi Jean-Sebastien It could well be simpler if, as you suggest, the conversion happens in the generated wrapper in this case. So we need such type inform
