Re: [Cross Subproject Discussion] options for SDO Java in Apache
Our current DAS implementation only has support for SDO types, and most of our users, if not all, are SDO users that need support for Relation Database stores. Based on this, I think this discussion should also consider having DAS together with SDO, either in Tuscany or in a different SDO TLP Incubator project. On Fri, Feb 15, 2008 at 2:39 AM, Mike Edwards <[EMAIL PROTECTED]> wrote: > Folks, > > A few observations inline. > > > Ron Gavlin wrote: > > I think consolidating the two SDO implementations under a single > > implementation would be good for the entire Apache SDO community. My > concern > > would be that no Tuscany SDO features be lost in the transition. The > > new implementation should provide most of what I can currently achieve > > using both EMF and Tuscany SDO. For example, EMF features like integrated > validation should be > > available in the new implementation before the old implementation is > dumped. It might be a good idea to poll the Tuscany SDO community to identify > the EMF features currently being used by Tuscany SDO community. It might also > be interesting to poll the Eclipse EMF SDO 1.0 community and ask the same > question. Maybe many of the existing Tuscany SDO test cases could be > re-written for either 1). the new implementation or 2). the CTS, to minimize > the loss of functionality during the transition. > > There is a fundamental tension here which I think it is important to > recognise. > > On the one hand, we want to ensure a lively and progressive Apache SDO > community that continually extends the capabilities of SDO to better > suit the needs of users. Innovation is a bit part of this story. > > On the other hand, we're trying to promote an open (and open source) > approach to the standardization of the SDO interfaces, to help ensure > consistent implementation of SDO across products both commercial and > open source. There is a JSR and a set of activities taking place in > OASIS for this. Part of that work is to produce an RI and a TCK, open > to all. However, an RI must be just that - an exemplary implementation > of the specification, the whole specification and nothing but the > specification. Similarly, the TCK must be testing compliance of > implementations with the specification, the whole specification and > nothing beyond the specification. This demands limitations on innovation. > > So, there is some careful work required in building both forward-looking > innovative capabilities and at the same time creating somewhat rigid RIs > and TCKs, which are inevitably tied to specific versions of a > specification. I think that the proposal to have a second SDO project > in Apache is regarded as one way to approach these conflicting > requirements. It may not be the only way, but at least it would provide > clear dividing lines that both contributors and users can understand easily. > > It will take some careful thought to combine these aspects within one > project in a way that works for all contributors and for all users. > > One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK > for SCA is because it fosters freedom in the implementation of new > capabilities that go well beyond the current SCA specifications. Some > of these will feed into future "standard specifications", I'm sure. > > > > > >>From my perspective, the priorities for Apache SDO moving forward should > be: > > > > 1. Align Apache SDO with the JAXB specification. > > The static SDO implementation should be JAXB-compliant. > > > > 2. Align Apache SDO with the JPA specification. It should be simple to use > a OpenJPA to persist SDO graphs. > > > > 3. Provide data binding support for popular Java open source WS stacks, > especially Axis2 and CXF. > > > > Yes, all good innovative stuff. > > I could toss in a few more, such as having an SDO implementation for > JavaScript to address AJAX applications. > > But how to square this with the RI and TCK with fixed functions matching > the SDO 2.1 specification? > > > > - Ron > > Yours, Mike. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with javabean data binding (empty arraylist)
Hi, The java Collection is not supported yet. We only support arrays at this point for web services. It shouldn't be too hard to add Collection support considering we already have arrays working. Can you open a JIRA so that we can track it? (http://issues.apache.org/jira/browse/TUSCANY) Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, February 15, 2008 9:10 AM Subject: Re: Problem with javabean data binding (empty arraylist) Pedro David Lopez wrote: Hi, I'm a new Apache Tuscany user and I have a problem Im using ws binding and return from the web services very simple javabeans. This beans have some strings, integers and arraylists atributtes. In other case is a simple java ArrayList. When I try web services the javabean received has only the strings and integer values but empty arraylist. (Always empty arraylist). My beans implements Serializable and i dont have exceptions. (no errors from data transformers but empty arraylist). ¿Some help? THANK YOU Pedro Lopez,Push The Button, S.L. Hi, I don't think that ArrayList is supported. List may be supported (but I'm not sure, maybe Raymond can jump in and shed some light here). Arrays are supported, I'm using arrays in some of my sample apps and have not seen any issues with them. Hope this helps. -- Jean-Sebastien - 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: Problem with javabean data binding (empty arraylist)
Pedro David Lopez wrote: Hi, I'm a new Apache Tuscany user and I have a problem Im using ws binding and return from the web services very simple javabeans. This beans have some strings, integers and arraylists atributtes. In other case is a simple java ArrayList. When I try web services the javabean received has only the strings and integer values but empty arraylist. (Always empty arraylist). My beans implements Serializable and i dont have exceptions. (no errors from data transformers but empty arraylist). ¿Some help? THANK YOU Pedro Lopez,Push The Button, S.L. Hi, I don't think that ArrayList is supported. List may be supported (but I'm not sure, maybe Raymond can jump in and shed some light here). Arrays are supported, I'm using arrays in some of my sample apps and have not seen any issues with them. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException with static SDO in BasicExtendedMetaData
On 15/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote: > > Is there a dynamic way to get the targetnamespace of > the schama that was used to generate the sdo? whoops, missed this part of the question ... So if your global element is always defined in the same namespace as the Type then you can use Type.getURI(). Kelvin.
Re: NullPointerException with static SDO in BasicExtendedMetaData
Hi Kelvin The targetnamespace of the schema that was used to generate an SDO class is probably stored in the metadata. Is there a way to query this namespace? Regards, Daniel. --- kelvin goodson <[EMAIL PROTECTED]> schrieb: > Daniel, > no the two xml representations are different. In > the first, the root > _element_ is signalled as being in the namespace > "http://abc.com/Sample";, > and therefore the type of the element is implied by > the known type > associated with the element, as defined in the > global element for Input in > the schema. In the second, the root element is not > described anywhere, we > don't have an implicit type, and therefore we must > explicitly state the > _type_ as coming from the namespace > "http://abc.com/Sample"; using the > xsi:type device. > > I believe what you want is the first form, and I > suspect what have been are > getting is the second, but when you alter your code > to give a non null > namespace you then start getting the first (and the > bonus is you will never > hit the concurrency issue, because all metadata is > defined before you use > it). > > Kelvin. Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException with static SDO in BasicExtendedMetaData
Daniel, no the two xml representations are different. In the first, the root _element_ is signalled as being in the namespace "http://abc.com/Sample";, and therefore the type of the element is implied by the known type associated with the element, as defined in the global element for Input in the schema. In the second, the root element is not described anywhere, we don't have an implicit type, and therefore we must explicitly state the _type_ as coming from the namespace "http://abc.com/Sample"; using the xsi:type device. I believe what you want is the first form, and I suspect what have been are getting is the second, but when you alter your code to give a non null namespace you then start getting the first (and the bonus is you will never hit the concurrency issue, because all metadata is defined before you use it). Kelvin. On 15/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote: > > Hi Kelvin, > > Yes, the root element varies as you described. > Btw: from the XML point of view, both variations are > equivalent, right? > > Is there a dynamic way to get the targetnamespace of > the schama that was used to generate the sdo? > > > Regards, Daniel > > --- kelvin goodson <[EMAIL PROTECTED]> > schrieb: > > > > I'm kind of surprised that the root element of the > > serialised document is in > > the target namespace of the Type, if you provide > > null as the input URI. So > > to check, the root element looks something like > > > > http://abc.com/Sample";> > > > > as opposed to > > > > http://abc.com/Sample"; > > xsi:type="tns:InputType"> > > > > yes? > > > > It's clear from the code path indicated by the > > exception you reported, that > > the metadata created during code generation due to > > the global elements in > > your schema are not being found at document creation > > time. I believe you > > should be supplying the namespace string to the > > CreateDocument call, and > > all will be well. > > > > Kelvin. > > > > Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. > www.yahoo.de/go > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: NullPointerException with static SDO in BasicExtendedMetaData
Hi Kelvin, Yes, the root element varies as you described. Btw: from the XML point of view, both variations are equivalent, right? Is there a dynamic way to get the targetnamespace of the schama that was used to generate the sdo? Regards, Daniel --- kelvin goodson <[EMAIL PROTECTED]> schrieb: > I'm kind of surprised that the root element of the > serialised document is in > the target namespace of the Type, if you provide > null as the input URI. So > to check, the root element looks something like > > http://abc.com/Sample";> > > as opposed to > > http://abc.com/Sample"; > xsi:type="tns:InputType"> > > yes? > > It's clear from the code path indicated by the > exception you reported, that > the metadata created during code generation due to > the global elements in > your schema are not being found at document creation > time. I believe you > should be supplying the namespace string to the > CreateDocument call, and > all will be well. > > Kelvin. Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Cross Subproject Discussion] options for SDO Java in Apache
Folks, A few observations inline. Ron Gavlin wrote: I think consolidating the two SDO implementations under a single implementation would be good for the entire Apache SDO community. My concern would be that no Tuscany SDO features be lost in the transition. The new implementation should provide most of what I can currently achieve using both EMF and Tuscany SDO. For example, EMF features like integrated validation should be available in the new implementation before the old implementation is dumped. It might be a good idea to poll the Tuscany SDO community to identify the EMF features currently being used by Tuscany SDO community. It might also be interesting to poll the Eclipse EMF SDO 1.0 community and ask the same question. Maybe many of the existing Tuscany SDO test cases could be re-written for either 1). the new implementation or 2). the CTS, to minimize the loss of functionality during the transition. There is a fundamental tension here which I think it is important to recognise. On the one hand, we want to ensure a lively and progressive Apache SDO community that continually extends the capabilities of SDO to better suit the needs of users. Innovation is a bit part of this story. On the other hand, we're trying to promote an open (and open source) approach to the standardization of the SDO interfaces, to help ensure consistent implementation of SDO across products both commercial and open source. There is a JSR and a set of activities taking place in OASIS for this. Part of that work is to produce an RI and a TCK, open to all. However, an RI must be just that - an exemplary implementation of the specification, the whole specification and nothing but the specification. Similarly, the TCK must be testing compliance of implementations with the specification, the whole specification and nothing beyond the specification. This demands limitations on innovation. So, there is some careful work required in building both forward-looking innovative capabilities and at the same time creating somewhat rigid RIs and TCKs, which are inevitably tied to specific versions of a specification. I think that the proposal to have a second SDO project in Apache is regarded as one way to approach these conflicting requirements. It may not be the only way, but at least it would provide clear dividing lines that both contributors and users can understand easily. It will take some careful thought to combine these aspects within one project in a way that works for all contributors and for all users. One of the reasons that Tuscany is NOT an RI and does NOT contain a TCK for SCA is because it fosters freedom in the implementation of new capabilities that go well beyond the current SCA specifications. Some of these will feed into future "standard specifications", I'm sure. From my perspective, the priorities for Apache SDO moving forward should be: 1. Align Apache SDO with the JAXB specification. The static SDO implementation should be JAXB-compliant. 2. Align Apache SDO with the JPA specification. It should be simple to use a OpenJPA to persist SDO graphs. 3. Provide data binding support for popular Java open source WS stacks, especially Axis2 and CXF. Yes, all good innovative stuff. I could toss in a few more, such as having an SDO implementation for JavaScript to address AJAX applications. But how to square this with the RI and TCK with fixed functions matching the SDO 2.1 specification? - Ron Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException with static SDO in BasicExtendedMetaData
I'm kind of surprised that the root element of the serialised document is in the target namespace of the Type, if you provide null as the input URI. So to check, the root element looks something like http://abc.com/Sample";> as opposed to http://abc.com/Sample"; xsi:type="tns:InputType"> yes? It's clear from the code path indicated by the exception you reported, that the metadata created during code generation due to the global elements in your schema are not being found at document creation time. I believe you should be supplying the namespace string to the CreateDocument call, and all will be well. Kelvin. On 15/02/2008, Daniel Peter <[EMAIL PROTECTED]> wrote: > > Hi Kelvin, let me clarify. > > The schemas used to generate the (static SDO) classes > all have their own targetnamespaces. E.g.: > http://abc.com/Sample";> > > > > > > > I convert an sdo object to XML this way: > MyType mySdo = … > > HelperContext hc = HelperProvider.getDefaultContext(); > XMLDocument xmldoc = > > hc.getXMLHelper().createDocument((DataObject)mySdo, > null, "Input"); > > … > hc.getXMLHelper().save(xmldoc, os, options); > > > When I pass null as rootElementUri as shown above, > then the targetNamespace as defined in the schema is > used in the produced XML. > Does the tuscany/emf code internally behave different > with regard to potential concurrency problems, if the > targetnamespace defined in the schema is explicitly > passed as rootElementUri argument? > > > Regards, Daniel. > > > --- kelvin goodson <[EMAIL PROTECTED]> > schrieb: > > > > So I think this is to do with the fact that you are > > not specifying a target > > namspace in the schema used to generate the classes. > > I see from the > > tools-test test case that uses the simpleNoTns.xsd > > schema, that the > > namespace URI for the generated artifacts is in fact > > the URI of the schema > > file on disk (not null or ""). So the global > > property created in the > > generated java won't be found with the lookup of > > (ns=null, name=Input) when > > calling XMLHelper.createDocument(dob, ns, name), > > hence the demand creation > > of the global property. Are you constrained to > > using a schema with no > > target namespace? If you had a namespace in your > > schema, and used it in > > the call to createDocument() then the underlying > > code would pick up the > > global property instance that is created by the > > generated factory, and you > > would then never hit this concurrency issue. > > > > Kelvin. > > > > > Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen > Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: NullPointerException with static SDO in BasicExtendedMetaData
Hi Kelvin, let me clarify. The schemas used to generate the (static SDO) classes all have their own targetnamespaces. E.g.: http://abc.com/Sample";> I convert an sdo object to XML this way: MyType mySdo = HelperContext hc = HelperProvider.getDefaultContext(); XMLDocument xmldoc = hc.getXMLHelper().createDocument((DataObject)mySdo, null, "Input"); hc.getXMLHelper().save(xmldoc, os, options); When I pass null as rootElementUri as shown above, then the targetNamespace as defined in the schema is used in the produced XML. Does the tuscany/emf code internally behave different with regard to potential concurrency problems, if the targetnamespace defined in the schema is explicitly passed as rootElementUri argument? Regards, Daniel. --- kelvin goodson <[EMAIL PROTECTED]> schrieb: > So I think this is to do with the fact that you are > not specifying a target > namspace in the schema used to generate the classes. > I see from the > tools-test test case that uses the simpleNoTns.xsd > schema, that the > namespace URI for the generated artifacts is in fact > the URI of the schema > file on disk (not null or ""). So the global > property created in the > generated java won't be found with the lookup of > (ns=null, name=Input) when > calling XMLHelper.createDocument(dob, ns, name), > hence the demand creation > of the global property. Are you constrained to > using a schema with no > target namespace? If you had a namespace in your > schema, and used it in > the call to createDocument() then the underlying > code would pick up the > global property instance that is created by the > generated factory, and you > would then never hit this concurrency issue. > > Kelvin. Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMS Binding: How to set the xml-format flag?
Hi ant, thank you for your quick repsonse. > I'd really like to come up with a better way to make this easier, how about > we add a new Tuscany specific attribute to the JMS binding SCDL to control > this, say format="XML|Object", with the default being format="XML" so the > current functionality remains if you don't define this. So that would look > like: I think having such an option would ease the usage of this Tuscany JMS Binding feature. Thinking of alternatives: I'm really not an expert in Tuscany's databinding capabilities but what do you think about configuring it via databinding? e.g. having of http://tuscany.apache.org/xmlns/sca/databinding/1.0"; name=" org.apache.tuscany.sca.databinding.javabeans.SimpleJavaDataBinding" /> would mean that JMS messages contain serialized Java-Objects? Regards, Philipp -Ursprüngliche Nachricht- > Von: ant elder [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 15. Februar 2008 09:34 > An: tuscany-user@ws.apache.org > Betreff: Re: JMS Binding: How to set the xml-format flag? > > On Fri, Feb 15, 2008 at 8:08 AM, Philipp Konradi <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > with the new 1.1 release of SCA Java the implementation of JMS Binding > > evolved to support XML-based JMS messages as SCA specs defines. What's > > really great. > > Now JMS binding supports two kinds of JMS messages XML-based and > > Java-Object-serialized ones. > > > > What I was wondering now is how the according xml-format flag can be > > set? Can it be done in the composite's JMS Binding configuration? > > > > Any help is very much appreciated, > > Philipp > > > > > The SCA specs do not define how to do this although it is possible with > the > current Tuscany code, see > http://apache.markmail.org/message/7nvfyxzavua5fypu > > I'd really like to come up with a better way to make this easier, how > about > we add a new Tuscany specific attribute to the JMS binding SCDL to control > this, say format="XML|Object", with the default being format="XML" so the > current functionality remains if you don't define this. So that would look > like: > > > > > > > > > Would this do what you need? Anyone else have comments or alternative > suggestions? > >...ant >
Re: JMS Binding: How to set the xml-format flag?
On Fri, Feb 15, 2008 at 8:08 AM, Philipp Konradi <[EMAIL PROTECTED]> wrote: > Hi, > > with the new 1.1 release of SCA Java the implementation of JMS Binding > evolved to support XML-based JMS messages as SCA specs defines. What's > really great. > Now JMS binding supports two kinds of JMS messages XML-based and > Java-Object-serialized ones. > > What I was wondering now is how the according xml-format flag can be > set? Can it be done in the composite's JMS Binding configuration? > > Any help is very much appreciated, > Philipp > The SCA specs do not define how to do this although it is possible with the current Tuscany code, see http://apache.markmail.org/message/7nvfyxzavua5fypu I'd really like to come up with a better way to make this easier, how about we add a new Tuscany specific attribute to the JMS binding SCDL to control this, say format="XML|Object", with the default being format="XML" so the current functionality remains if you don't define this. So that would look like: Would this do what you need? Anyone else have comments or alternative suggestions? ...ant
JMS Binding: How to set the xml-format flag?
Hi, with the new 1.1 release of SCA Java the implementation of JMS Binding evolved to support XML-based JMS messages as SCA specs defines. What's really great. Now JMS binding supports two kinds of JMS messages XML-based and Java-Object-serialized ones. What I was wondering now is how the according xml-format flag can be set? Can it be done in the composite's JMS Binding configuration? Any help is very much appreciated, Philipp
