[jira] Closed: (TUSCANY-884) Update JSON-RPC binding and sample to use Dojo Toolkit support SMD
[ https://issues.apache.org/jira/browse/TUSCANY-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-884. - Resolution: Fixed Has been applied. Good stuff Birt, thanks for the patch. Update JSON-RPC binding and sample to use Dojo Toolkit support SMD -- Key: TUSCANY-884 URL: https://issues.apache.org/jira/browse/TUSCANY-884 Project: Tuscany Issue Type: Improvement Components: Java SCA JsonRpc Binding Affects Versions: Java-Mx Reporter: Bert Lamb Assigned To: ant elder Attachments: dojo-support.patch I have created a patch (which I will attach shortly) that adds SMD support to the JSON-RPC binding, allowing easy use of the Dojo toolkit to create AJAX frontends that make use of JSON-RPC services exposed using Tuscany. I have also updated the JSON-RPC sample to show how to use Dojo to access Tuscany JSON-RPC services. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ doubts about Type.h
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: Thanks Pete, I thought there would be an easier way to do this. But if you say so, I think it's the only way. Thanks again! That is what is in the spec. Maybe we could propose a bool Type::hasProperty(std::string propertyName); method Cheers, Adriano Crestani On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote: On 10/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: I'm begginer with C++ and I have one doubt about the function defined in Type.h: virtual SDO_API const Property getProperty(const char* propertyName) const = 0. It's supposed to return a reference to a Property object that has the name equal to the parameter propertyName, but if there is no Property object with this name? What does this function return? It would through a SDOPropertyNotFoundException. I tried to do this... if (type.getProperty(ID) == NULL) ...but as long as far as I know it's not possible. Is there a way to check if the function has found Property object with the specified name or not. Adriano Crestani There is no easy way to do this. You would need to wrap the getProperty in a try/catch block. Cheers, -- Pete -- Pete
[jira] Closed: (TUSCANY-874) NPE occurs on binding.ws when JAXB data type gets involved in service
[ https://issues.apache.org/jira/browse/TUSCANY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-874. - Resolution: Fixed NPE occurs on binding.ws when JAXB data type gets involved in service - Key: TUSCANY-874 URL: https://issues.apache.org/jira/browse/TUSCANY-874 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: Li Shen Assigned To: Raymond Feng Attachments: helloworldws.zip Caused by: java.lang.NullPointerException at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:570) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522) at org.apache.tuscany.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:55) at org.apache.tuscany.databinding.jaxb.JAXB2Node.transform(JAXB2Node.java:45) Enclosed web app is modified from the axis2 helloworldws sample and it could be used to reproduce this error: 1) mvn package and deploy the generated war to tomcat 2) visit http://localhost:8080/sample-helloworldws/helloworld.jsp to check for error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-737) Adding extensions to tuscany war pluging results in non - intialized webapp
[ https://issues.apache.org/jira/browse/TUSCANY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-737. - Resolution: Fixed Fixed Adding extensions to tuscany war pluging results in non - intialized webapp --- Key: TUSCANY-737 URL: https://issues.apache.org/jira/browse/TUSCANY-737 Project: Tuscany Issue Type: Bug Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Critical Fix For: Java-M2 When some dependency extensions are add to the war plugin (see: sampleapps\bigbank\webclient\pom.xml as an example) tuscany boot jars: commonj-api_r1.1-1.0-incubator-M2-SNAPSHOT.jar core-1.0-incubator-M2-SNAPSHOT.jar stax-api-1.0.1.jar tuscany-spi-1.0-incubator-M2-SNAPSHOT.jar wstx-asl-2.9.3.jar are moved to the web-inf/lib resulting in class not found errors for org/apache/tuscany/spi/model/Implementation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building, Running and Debugging SCA Standalone samples...
Seems like this could be a very useful this to have on the wiki... in line with a number of recent comments obviously isn't clear enough on existing pages... On 10/01/07, Luciano Resende [EMAIL PROTECTED] wrote: I have been thinking about writing something about this subject for a long time, and trying to get the momentum from Francesco recent post, I have published the following post describing how to build, run and debug standalone SCA applications on my blog. http://lresende.blogspot.com/2007_01_01_lresende_archive.html#116840396127884388 Francesco, thanks for the detailed steps : http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00431.html Please feel free to send your feedback, and I hope it helps other users in the community. -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende
TUSCANY-1039 help
Looking at http://issues.apache.org/jira/browse/TUSCANY-1039 Right now for me the axis2 binding is not loading in a standalone because of this: There is a NoClassDefFoundError loading org.apache.tuscany.binding.axis2.Axis2BindingBuilder because it's not finding javax/servlet/Servlet. I know ultimately it should not reference this, but lets put this aside for now. The scdl for this binding has axis2.0 binding as a dependency and that has servlet-api. I also locally changed the scope directly there to compile to make sure it was required. Debugging I found org.apache.tuscany.spi.deployer.CompositeClassLoader is the classloader and I noticed in the fields ucp.path where there are the other dependencies listed too the URL m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar Just to make certain I unzipped that jar to find javax/servlet/Servlet.class I'm at a loss as to why this isn't loading? Is javax/ special ? Only loaded by the system extension loader ? Any insight would be appreciated. thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1019) WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463905 ] Scott Kurz commented on TUSCANY-1019: - Thanks for investigating. I'd assume you'd be able to use any compatible Java mapping. For example if your service intf is described by an interface.wsdl, the service impl could be written to a mapped-style Java intf using static SDO. One Java client of this service might be written to a non-mapped Java intf using a single dynamic SDO for input,output. Another client might use JAXB. But the assembly and Java CI specs leave this up for interpretation, I'd agree. I think there are even more issues needing clarification if the service intf. is described as an interface.java w/ static SDO or JAXB types in the interface signatures... but that's starting to expand the discussion past the scope of this JIRA. Also, I believe there would be runtime changes needed in addition to tooling changes to allow the doc-lit-wrapped WSDL combined with non-wrapper-style Java mapping to flow through the databinding code. WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL - Key: TUSCANY-1019 URL: https://issues.apache.org/jira/browse/TUSCANY-1019 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools, Specification Affects Versions: Java-Mx Reporter: Scott Kurz Assigned To: Jean-Sebastien Delfino It is currently possible to use the WSDL2Java tooling to do each of: * start w/ doc-lit-wrapped WSDL and generate a wrapper-style Java mapping * start w/ doc-lit-nonwrapped WSDL and generate a non-wrapper-style Java mapping However it is not possible to start w/ doc-lit-wrapped WSDL and generate a non-wrapper-style Java mapping. You might want to do this in order to work with the input as a single SDO rather than having the individual child elements appear on the Java signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec proposal for setting the current CompositeContext
I wasn't no - I was trying to keep it small and just address the issue with what's there in that there is no way to set the value. In Tuscany we added the SCA class but never proposed that to the spec group and in practice it is not working well. On the other hand, there are issues with this API in general as Jim has mentioned earlier. Do you think we should start to tackle those? -- Jeremy On Jan 10, 2007, at 6:13 PM, scabooz wrote: Hi Jeremy, Are you also going to propose the removal of the getContext() API? Dave - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, January 10, 2007 5:20 PM Subject: Re: Spec proposal for setting the current CompositeContext On Jan 10, 2007, at 1:54 PM, Raymond Feng wrote: Hi, Is the setContext() going to be used by applications? I guess I need a bit more background. It depends on the application. It would be used by a program that was embedding or bootstrapping an SCA runtime; it's not likely to be used by programs just using SCA components (and, of course, SCA components themselves shouldn't be using CurrentCompositeContext at all). -- 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]
Re: Spec proposal for setting the current CompositeContext
Yes. I don't think we'd need the get API anymore because your proposal (as I read the API) not only sets the context but also inits the context as current and returns it to the bootstrapping environment. I don't know what the environment would do with a get API since the set returns the same thing. Maybe there's some convenience or completeness reason to keep it, but I don't see a functional reason. Did I read too much into the set API? Dave - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, January 11, 2007 9:59 AM Subject: Re: Spec proposal for setting the current CompositeContext I wasn't no - I was trying to keep it small and just address the issue with what's there in that there is no way to set the value. In Tuscany we added the SCA class but never proposed that to the spec group and in practice it is not working well. On the other hand, there are issues with this API in general as Jim has mentioned earlier. Do you think we should start to tackle those? -- Jeremy On Jan 10, 2007, at 6:13 PM, scabooz wrote: Hi Jeremy, Are you also going to propose the removal of the getContext() API? Dave - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, January 10, 2007 5:20 PM Subject: Re: Spec proposal for setting the current CompositeContext On Jan 10, 2007, at 1:54 PM, Raymond Feng wrote: Hi, Is the setContext() going to be used by applications? I guess I need a bit more background. It depends on the application. It would be used by a program that was embedding or bootstrapping an SCA runtime; it's not likely to be used by programs just using SCA components (and, of course, SCA components themselves shouldn't be using CurrentCompositeContext at all). -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest code from tuscany cannot find repositories
Hasan,
I'm sorry I dropped the ball with your enquiry. I have only just spotted
your response when searching the mail archive. I am now seeing similar
things for the woodstox dependency and I haven't got to the bottom of it
yet. I notice that for all versions of woodstox at
http://repo1.maven.org/maven2/woodstox/wstx-asl/ there are no wstx-asl*.pom
files.
Similarly at
http://mvnrepository.com/artifact/org.codehaus.woodstox/wstx-asl/3.2.0 the
link to view the pom file at
ftp://ibiblio.org/pub/packages/maven2/org/codehaus/woodstox/wstx-asl/3.2.0/wstx-asl-3.2.0.pom
fails with file not found.
Do you still have your problem?
Regards, Kelvin.
On 04/01/07, Hasan Muhammad [EMAIL PROTECTED] wrote:
Kelvin,
The problem may not be retrieving the jar file but the pom file in the
first
place as shown below.
[INFO] snapshot
org.apache.maven.plugins:maven-assembly-plugin:2.2-SNAPSHOT:che
cking for updates from eclipse.emf
[WARNING] repository metadata for: 'snapshot
org.apache.maven.plugins:maven-asse
mbly-plugin:2.2-SNAPSHOT' could not be retrieved from repository:
eclipse.emf du
e to an error: Error transferring file
[INFO] Repository 'eclipse.emf' will be blacklisted
[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack-javadoc}]
I am especially worried about the line [INFO] Repository 'eclipse.emf'
will
be blacklisted in the error above.. It is here that it is failing to
begin
with and hence cant retrieve the jar files.
regards, Hasan
On 1/4/07, kelvin goodson [EMAIL PROTECTED] wrote:
Hasan
I just removed the jar from my repository and rebuilt. I saw
Downloading:
http://download.eclipse.org/tools/emf/maven2/org/eclipse/emf/common/2.2.1/common-2.2.1.jar
152K downloaded
in my build log.
Regards, Kelvin.
On 04/01/07, Hasan Muhammad [EMAIL PROTECTED] wrote:
Hi,
I checked out the latest code from Tuscany, cleaned up my repo
totally.
When
i try to do an mvn on SDO, it cannot get the EMF repositories.. Any
ideas
as
to whether this is my system, or the jars are not really available on
the
repo site for download ?? This is really blocking me...
[INFO] Building Tuscany SDO Implementation
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 8 resources
[INFO] Copying 0 resource to META-INF
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/emf/ecore-change/2.2.1/ecore-change-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.emf/poms/ecore-ch
ange-2.2.1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository)
Downloading:
http://repo1.maven.org/maven2/org/eclipse/emf/ecore-change/2.2.1/ec
ore-change-2.2.1.pom
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org
/maven2)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/emf/ecore/2.2.1/ecore-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.emf/poms/ecore-2.
2.1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository)
Downloading:
http://repo1.maven.org/maven2/org/eclipse/emf/ecore/2.2.1/ecore-2.2
.1.pom
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org
/maven2)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/xsd/xsd/2.2.1/xsd-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.xsd/poms/xsd-2.2.
1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository)
Downloading:
http://repo1.maven.org/maven2/org/eclipse/xsd/xsd/2.2.1/xsd-2.2.1.p
om
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org
/maven2)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/emf/common/2.2.1/common-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.emf/poms/common-2
.2.1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository)
Downloading:
[jira] Updated: (TUSCANY-909) Current Tuscany driver Spec API inconsistence with Spec 0.95
[ https://issues.apache.org/jira/browse/TUSCANY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-909: --- Attachment: TUSCANY-909.patch Current Tuscany driver Spec API inconsistence with Spec 0.95 - Key: TUSCANY-909 URL: https://issues.apache.org/jira/browse/TUSCANY-909 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: WIndows XP Reporter: Yang Lei Assigned To: Jean-Sebastien Delfino Attachments: TUSCANY-909.patch 1.API(annotation) differences between the current driver and 0.95 spec CompositeContext: 0.95 Spec v.s. current Tuscany driver (incubator-M2) getName -- getCompositeName getURI -- getCompositeURI getMetaData -- none Annotation difference: there is no annotation @ComponentMetadata. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[ https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-824: Assignee: Raymond Feng DataBinding: Is it a concern of Programming Model vs. Assembly? --- Key: TUSCANY-824 URL: https://issues.apache.org/jira/browse/TUSCANY-824 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Reporter: ant elder Assigned To: Raymond Feng Priority: Blocker Fix For: Java-M2 There have been some question about the DataBinding framework and if it should be a concern of the Programming Model vs. Assembly? See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html and a follow up mention in: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest code from tuscany cannot find repositories
I have now fixed the woodstox issue by changing the groupid and adding
another repository to the sdo/impl/pom.xml. The repositories that were
already listed and contained a woodstox jar did not have pom files. I
haven't seen this with emf, but it sounds like the symptom you were
experiencing. Perhaps it was just a temporary network/server problem?
Regards, kelvin.
On 11/01/07, kelvin goodson [EMAIL PROTECTED] wrote:
Hasan,
I'm sorry I dropped the ball with your enquiry. I have only just
spotted your response when searching the mail archive. I am now seeing
similar things for the woodstox dependency and I haven't got to the bottom
of it yet. I notice that for all versions of woodstox at
http://repo1.maven.org/maven2/woodstox/wstx-asl/ there are no
wstx-asl*.pom files.
Similarly at
http://mvnrepository.com/artifact/org.codehaus.woodstox/wstx-asl/3.2.0 the
link to view the pom file at
ftp://ibiblio.org/pub/packages/maven2/org/codehaus/woodstox/wstx-asl/3.2.0/wstx-asl-3.2.0.pom
fails with file not found.
Do you still have your problem?
Regards, Kelvin.
On 04/01/07, Hasan Muhammad [EMAIL PROTECTED] wrote:
Kelvin,
The problem may not be retrieving the jar file but the pom file in the
first
place as shown below.
[INFO] snapshot
org.apache.maven.plugins:maven-assembly-plugin:2.2-SNAPSHOT:che
cking for updates from eclipse.emf
[WARNING] repository metadata for: 'snapshot
org.apache.maven.plugins:maven-asse
mbly-plugin:2.2-SNAPSHOT' could not be retrieved from repository:
eclipse.emf du
e to an error: Error transferring file
[INFO] Repository 'eclipse.emf' will be blacklisted
[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack-javadoc}]
I am especially worried about the line [INFO] Repository 'eclipse.emf'
will
be blacklisted in the error above.. It is here that it is failing to
begin
with and hence cant retrieve the jar files.
regards, Hasan
On 1/4/07, kelvin goodson [EMAIL PROTECTED] wrote:
Hasan
I just removed the jar from my repository and rebuilt. I saw
Downloading:
http://download.eclipse.org/tools/emf/maven2/org/eclipse/emf/common/2.2.1/common-2.2.1.jar
152K downloaded
in my build log.
Regards, Kelvin.
On 04/01/07, Hasan Muhammad [EMAIL PROTECTED] wrote:
Hi,
I checked out the latest code from Tuscany, cleaned up my repo
totally.
When
i try to do an mvn on SDO, it cannot get the EMF repositories.. Any
ideas
as
to whether this is my system, or the jars are not really available
on
the
repo site for download ?? This is really blocking me...
[INFO] Building Tuscany SDO Implementation
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 8 resources
[INFO] Copying 0 resource to META-INF
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/emf/ecore-change/2.2.1/ecore-change-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.emf/poms/ecore-ch
ange-2.2.1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository )
Downloading:
http://repo1.maven.org/maven2/org/eclipse/emf/ecore-change/2.2.1/ec
ore-change-2.2.1.pom
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org
/maven2)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/emf/ecore/2.2.1/ecore-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.emf/poms/ecore-2 .
2.1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository )
Downloading:
http://repo1.maven.org/maven2/org/eclipse/emf/ecore/2.2.1/ecore-2.2
.1.pom
[WARNING] Unable to get resource from repository central (
http://repo1.maven.org
/maven2)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/eclipse
/xsd/xsd/2.2.1/xsd-2.2.1.pom
[WARNING] Unable to get resource from repository apache.incubator (
http://people
.apache.org/repo/m2-incubating-repository/)
Downloading:
http://ws.zones.apache.org/repository/org.eclipse.xsd/poms/xsd-2.2.
1.pom
[WARNING] Unable to get resource from repository
apache.ws.m1.snapshots
(http://
ws.zones.apache.org/repository)
Downloading:
http://repo1.maven.org/maven2/org/eclipse/xsd/xsd/2.2.1/xsd-2.2.1.p
om
[WARNING] Unable to get resource from repository central (
[jira] Resolved: (TUSCANY-418) JavaScript components using E4X with service references
[ https://issues.apache.org/jira/browse/TUSCANY-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-418. -- Resolution: Fixed JavaScript components using E4X with service references --- Key: TUSCANY-418 URL: https://issues.apache.org/jira/browse/TUSCANY-418 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M2 Attachments: Tuscany-JS-E4X-J418-Aug-26.diff Currently JavaScript components cannot use E4X when calling service references -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-437) StAX loader framework cannot handle xsi:type
[
https://issues.apache.org/jira/browse/TUSCANY-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng reassigned TUSCANY-437:
Assignee: Raymond Feng
StAX loader framework cannot handle xsi:type
--
Key: TUSCANY-437
URL: https://issues.apache.org/jira/browse/TUSCANY-437
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2, Java-Mx
Reporter: Raymond Feng
Assigned To: Raymond Feng
Fix For: Java-M2
The current StAX loader registration is against the QName of the element. It
cannot handle the xsi:type variant.
For example, if I change the sca.module for Helloworld to use the
xsi:type (which is legal against the SCA xsd).
module xmlns=http://www.osoa.org/xmlns/sca/0.9;
xmlns:v=http://www.osoa.org/xmlns/sca/values/0.9;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
name=helloworld
component name=HelloWorldServiceComponent
!--
implementation.java class=helloworld.HelloWorldImpl/
--
implementation xsi:type=JavaImplementation
class=helloworld.HelloWorldImpl/
/component
/module
I'm getting the following exception:
Exception in thread main
org.apache.tuscany.core.config.ConfigurationLoadException: Unrecognized
element [{http://www.osoa.org/xmlns/sca/0.9}implementation]
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:62)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:76)
at
org.apache.tuscany.core.loader.assembly.ComponentLoader.load(ComponentLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.loader.assembly.CompositeLoader.loadComposite(CompositeLoader.java:43)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:41)
at
org.apache.tuscany.core.loader.assembly.ModuleLoader.load(ModuleLoader.java:1)
at
org.apache.tuscany.core.loader.impl.StAXLoaderRegistryImpl.load(StAXLoaderRegistryImpl.java:66)
at
org.apache.tuscany.core.config.impl.StAXModuleComponentConfigurationLoaderImpl.loadModule(StAXModuleComponentConfigurationLoaderImpl.java:51)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:142)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:132)
at
org.apache.tuscany.core.config.impl.AbstractModuleComponentConfigurationLoader.loadModuleComponent(AbstractModuleComponentConfigurationLoader.java:100)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:103)
at
org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java:67)
at helloworld.HelloWorldClient.main(HelloWorldClient.java:32)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeContext method names
Hi, You first need to configure the ssh in user.home/.m2/settings.xml with the following content: ?xml version=1.0 encoding=UTF-8? settings servers server idapache.snapshots/id usernameyour_apache_id/username !-- Default value is ~/.ssh/id_dsa -- privateKeyuser.home\.ssh\id_dsa/privateKey passphraseyour_password/passphrase /server /servers /settings Then you can run mvn deploy under the modules to upload the SNAPSHOT version of the artifact. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, January 11, 2007 8:52 AM Subject: Re: CompositeContext method names Jeremy Boynes wrote: Can't be sure without seeing the changes - including a patch would be helpful. In general, this sounds like an incompatible change (it's renaming methods) so republishing the snapshots would be a good move. If it was a less intrusive change (e.g. adding a method) then just committing would be enough. -- Jeremy On Jan 10, 2007, at 5:56 PM, Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Jim Marino wrote: On Jan 8, 2007, at 4:26 PM, Jean-Sebastien Delfino wrote: The names of some of the methods on org.osoa.sca.CompositeContext do not match the API described in the 0.95 Java SCA CI specification (this was reported as http://issues.apache.org/jira/browse/TUSCANY-909). I have checked the latest SCA spec docs and the spec mailing lists and could not find any indication that the names on our definition of CompositeContext are the correct ones. I'm planning on making the following changes: - rename getCompositeName() to getName() - rename getCompositeURI() to getURI() Jim, you've been following this more closely than me, is this the right change? are the spec documents up to date and our code needs to be adjusted? or is it the other way around? Those have not changed to my knowledge (or at least I can't remember), so it is probably a simple oversight on our part. There are a number of changes where the spec needs to be updated in other areas (e.g. scopes), that I'm in the process of doing now. Jim Thanks, --Jean-Sebastien OK thanks! I'll make the code match the spec then :) I have the changes ready, affecting CompositeContext in the spec/sca project and 3 other classes in kernel. What is the best way to apply the changes? Is committing the spec and kernel changes sufficient? or do I need to republish the spec and kernel snapshots? Thanks, --Jean-Sebastien I have attached a patch to JIRA TUSCANY-909. The change is trivial, except for the fact that it affects two different modules, spec and kernel. Could somebody post here how to republish the snapshots and I'll try to do it. Thanks. -- 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]
[Java SDO and SCA] repository pom files missing for woodstox and jaxen artifacts
I've just managed to fix one of these issues, where none of the repositories listed in our pom had pom files to accompany the woodstox distribution. I added http://repository.codehaus.org to the local sdo/impl/pom.xml (and incidentally updated the groupId at the same time) This allowed my build to progress, but now it is failing in the same way on the jaxen artifact Downloading: http://download.eclipse.org/tools/emf/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: jaxen:jaxen Reason: Error getting POM for 'jaxen:jaxen' from the repository: Error transferring file jaxen:jaxen:pom:1.1-beta-10 from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), eclipse.emf (http://download.eclipse.org/tools/emf/maven2), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/) So there are two points here. One is thaat my local change in sdo/impl may need either replicating elsewhere or raising up the project hierarchy so that it affects other woodstox dependencies. The other is that I need a similar fix for jaxen. Any pointers as to why these failures are happening now? Regards, Kelvin.
Re: [Java SDO and SCA] repository pom files missing for woodstox and jaxen artifacts
Hi, Kelvin. I just checked http://repo1.maven.org/maven2/org/codehaus/woodstox/wstx-asl/ and I can see the POM files are there for various version. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, January 11, 2007 9:09 AM Subject: [Java SDO and SCA] repository pom files missing for woodstox and jaxen artifacts I've just managed to fix one of these issues, where none of the repositories listed in our pom had pom files to accompany the woodstox distribution. I added http://repository.codehaus.org to the local sdo/impl/pom.xml (and incidentally updated the groupId at the same time) This allowed my build to progress, but now it is failing in the same way on the jaxen artifact Downloading: http://download.eclipse.org/tools/emf/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: jaxen:jaxen Reason: Error getting POM for 'jaxen:jaxen' from the repository: Error transferring file jaxen:jaxen:pom:1.1-beta-10 from the specified remote repositories: apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache.ws.m1.snapshots (http://ws.zones.apache.org/repository), eclipse.emf (http://download.eclipse.org/tools/emf/maven2), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/) So there are two points here. One is thaat my local change in sdo/impl may need either replicating elsewhere or raising up the project hierarchy so that it affects other woodstox dependencies. The other is that I need a similar fix for jaxen. Any pointers as to why these failures are happening now? Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ doubts about Type.h
if(hasProperty) getProperty else is 2 trips, either which or try/catch seems a Programming Model which could be further simplified such as const Property _*_ getProperty (const std::string* propertyName) const or const Property _*_ getProperty (const QName propertyName) const On the other hand, getPropertyIndex also throws exception which could return -1/MAX_INT instead. The Java counterpart has specified less exception to make a easier Programming Model, maybe C++ spec can consider that too. On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote: On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: Thanks Pete, I thought there would be an easier way to do this. But if you say so, I think it's the only way. Thanks again! That is what is in the spec. Maybe we could propose a bool Type::hasProperty(std::string propertyName); method Cheers, Adriano Crestani On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote: On 10/01/07, Adriano Crestani [EMAIL PROTECTED] wrote: I'm begginer with C++ and I have one doubt about the function defined in Type.h: virtual SDO_API const Property getProperty(const char* propertyName) const = 0. It's supposed to return a reference to a Property object that has the name equal to the parameter propertyName, but if there is no Property object with this name? What does this function return? It would through a SDOPropertyNotFoundException. I tried to do this... if (type.getProperty(ID) == NULL) ...but as long as far as I know it's not possible. Is there a way to check if the function has found Property object with the specified name or not. Adriano Crestani There is no easy way to do this. You would need to wrap the getProperty in a try/catch block. Cheers, -- Pete -- Pete -- Yang ZHONG
Re: SDO C++ doubts about Type.h
I think it wouldn't be a good idea, because if you want to check if there is
a property with the specified name using hasProperty method and later to get
the property with getProperty(string) it would look for the property name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to get the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any property
with the specified name it also throws a SDOPropertyNotFoundException. I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the property name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Thanks Pete, I thought there would be an easier way to do this. But if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I'm begginer with C++ and I have one doubt about the function
defined
in
Type.h: virtual SDO_API const Property getProperty(const char*
propertyName) const = 0. It's supposed to return a reference to a
Property
object that has the name equal to the parameter propertyName, but if
there
is no Property object with this name? What does this function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty(ID) == NULL)
...but as long as far as I know it's not possible. Is there a way to
check
if the function has found Property object with the specified name or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
Re: SDO C++ doubts about Type.h
The reason getProperty throws an exception is that it's a exceptional
condition ;-)
The expectation is that you KNOW the names of the properties on the SDO that
you are dealing with. If not, then you would use getPropertyList or
getInstanceProperties and iterate over the list.
I'm assuming in your case that ALL your DO's are expected to have a
particular property (ID)??. In which case isn't it an error if they don't =
exception?
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I think it wouldn't be a good idea, because if you want to check if there
is
a property with the specified name using hasProperty method and later to
get
the property with getProperty(string) it would look for the property name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to get the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any property
with the specified name it also throws a SDOPropertyNotFoundException. I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the property
name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
http://osoa.org/display/Main/Service+Data+Objects+Specifications
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Thanks Pete, I thought there would be an easier way to do this. But if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I'm begginer with C++ and I have one doubt about the function
defined
in
Type.h: virtual SDO_API const Property getProperty(const char*
propertyName) const = 0. It's supposed to return a reference to
a
Property
object that has the name equal to the parameter propertyName, but
if
there
is no Property object with this name? What does this function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty(ID) == NULL)
...but as long as far as I know it's not possible. Is there a way
to
check
if the function has found Property object with the specified name
or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
--
Pete
Re: SDO C++ doubts about Type.h
Maybe the best solution would be to return a PropertyPtr (we do not like
returning raw pointers to our internal data so this is better than Property*
... avoids lifetime of the Pointee problems):
PropertyPtr x = myType-getProperty(ID);
if (x)
{
x-what_ever_it_is_you_want_to_do_with_the_property??
}
On 11/01/07, Pete Robbins [EMAIL PROTECTED] wrote:
The reason getProperty throws an exception is that it's a exceptional
condition ;-)
The expectation is that you KNOW the names of the properties on the SDO
that you are dealing with. If not, then you would use getPropertyList or
getInstanceProperties and iterate over the list.
I'm assuming in your case that ALL your DO's are expected to have a
particular property (ID)??. In which case isn't it an error if they don't =
exception?
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I think it wouldn't be a good idea, because if you want to check if
there is
a property with the specified name using hasProperty method and later to
get
the property with getProperty(string) it would look for the property
name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to get the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any
property
with the specified name it also throws a SDOPropertyNotFoundException. I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the property
name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
http://osoa.org/display/Main/Service+Data+Objects+Specifications
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Thanks Pete, I thought there would be an easier way to do this. But
if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I'm begginer with C++ and I have one doubt about the function
defined
in
Type.h: virtual SDO_API const Property getProperty(const char*
propertyName) const = 0. It's supposed to return a reference
to a
Property
object that has the name equal to the parameter propertyName,
but if
there
is no Property object with this name? What does this function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty (ID) == NULL)
...but as long as far as I know it's not possible. Is there a
way to
check
if the function has found Property object with the specified
name or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
--
Pete
--
Pete
Re: SDO C++ doubts about Type.h
Agree, neither Property* nor Property tracks references.
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
Maybe the best solution would be to return a PropertyPtr (we do not like
returning raw pointers to our internal data so this is better than
Property*
... avoids lifetime of the Pointee problems):
PropertyPtr x = myType-getProperty(ID);
if (x)
{
x-what_ever_it_is_you_want_to_do_with_the_property??
}
On 11/01/07, Pete Robbins [EMAIL PROTECTED] wrote:
The reason getProperty throws an exception is that it's a exceptional
condition ;-)
The expectation is that you KNOW the names of the properties on the SDO
that you are dealing with. If not, then you would use getPropertyList or
getInstanceProperties and iterate over the list.
I'm assuming in your case that ALL your DO's are expected to have a
particular property (ID)??. In which case isn't it an error if they
don't =
exception?
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I think it wouldn't be a good idea, because if you want to check if
there is
a property with the specified name using hasProperty method and later
to
get
the property with getProperty(string) it would look for the property
name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to get
the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any
property
with the specified name it also throws a SDOPropertyNotFoundException.
I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the property
name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
http://osoa.org/display/Main/Service+Data+Objects+Specifications
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Thanks Pete, I thought there would be an easier way to do this.
But
if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED]
wrote:
I'm begginer with C++ and I have one doubt about the function
defined
in
Type.h: virtual SDO_API const Property getProperty(const
char*
propertyName) const = 0. It's supposed to return a reference
to a
Property
object that has the name equal to the parameter propertyName,
but if
there
is no Property object with this name? What does this function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty (ID) == NULL)
...but as long as far as I know it's not possible. Is there a
way to
check
if the function has found Property object with the specified
name or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
--
Pete
--
Pete
--
Yang ZHONG
[jira] Updated: (TUSCANY-1040) DAS C++
[ https://issues.apache.org/jira/browse/TUSCANY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani updated TUSCANY-1040: -- Attachment: DAS_CPP_01_11_2007.zip DAS C++ --- Key: TUSCANY-1040 URL: https://issues.apache.org/jira/browse/TUSCANY-1040 Project: Tuscany Issue Type: New Feature Components: C++ SDO Affects Versions: Wish list Reporter: Luciano Resende Fix For: Wish list Attachments: DAS_CPP.zip, DAS_CPP_01_11_2007.zip Create a version of DAS in C++ integrating with SDO C++ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ doubts about Type.h
Just one more thought. It comes down to how often you think the property
will not be found. returning a pointer (or even a re counting ptr object)
requires the user to ALWAYS code an if (xxx) following the getProperty. This
is why the API is as it is today so that the normal use case is simple for
the user.
I'd like to understand the use case where we are trying to do
Type::getProperty(propname) where you are not expecting propname to be a
property.
Cheers,
On 11/01/07, Yang ZHONG [EMAIL PROTECTED] wrote:
Agree, neither Property* nor Property tracks references.
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
Maybe the best solution would be to return a PropertyPtr (we do not like
returning raw pointers to our internal data so this is better than
Property*
... avoids lifetime of the Pointee problems):
PropertyPtr x = myType-getProperty(ID);
if (x)
{
x-what_ever_it_is_you_want_to_do_with_the_property??
}
On 11/01/07, Pete Robbins [EMAIL PROTECTED] wrote:
The reason getProperty throws an exception is that it's a exceptional
condition ;-)
The expectation is that you KNOW the names of the properties on the
SDO
that you are dealing with. If not, then you would use getPropertyList
or
getInstanceProperties and iterate over the list.
I'm assuming in your case that ALL your DO's are expected to have a
particular property (ID)??. In which case isn't it an error if they
don't =
exception?
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I think it wouldn't be a good idea, because if you want to check if
there is
a property with the specified name using hasProperty method and
later
to
get
the property with getProperty(string) it would look for the property
name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to get
the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any
property
with the specified name it also throws a
SDOPropertyNotFoundException.
I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the
property
name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
http://osoa.org/display/Main/Service+Data+Objects+Specifications
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Thanks Pete, I thought there would be an easier way to do this.
But
if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED]
wrote:
I'm begginer with C++ and I have one doubt about the
function
defined
in
Type.h: virtual SDO_API const Property getProperty(const
char*
propertyName) const = 0. It's supposed to return a
reference
to a
Property
object that has the name equal to the parameter
propertyName,
but if
there
is no Property object with this name? What does this
function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty (ID) == NULL)
...but as long as far as I know it's not possible. Is there
a
way to
check
if the function has found Property object with the specified
name or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
--
Pete
--
Pete
--
Yang ZHONG
--
Pete
[jira] Created: (TUSCANY-1045) NPE caused by null Constructor Definition when using componentType side file
NPE caused by null Constructor Definition when using componentType side file
-
Key: TUSCANY-1045
URL: https://issues.apache.org/jira/browse/TUSCANY-1045
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Reporter: Lou Amodeo
r494421.The test-CallBackCType test is failing with a NPE. This test case
previously worked when using the workaround for Tuscany-967. It is using a
componentType side file to specify a callback interface shown below.Problem
appears that ctodDef is null.
// setup constructor injection
ConstructorDefinition? ctorDef = componentType.getConstructorDefinition();
java:120 Constructor? constr = ctorDef.getConstructor(); Constructor
Definition is null.
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.buil
d(JavaComponentBuilder.java:120)
at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.buil
d(JavaComponentBuilder.java:53)
at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegi
stryImpl.java:106)
at org.apache.tuscany.core.implementation.composite.CompositeBuilder.bui
ld(CompositeBuilder.java:56)
at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegi
stryImpl.java:106)
at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java
:142)
at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:97)
at org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl
(AbstractRuntime.java:148)
at org.apache.tuscany.sca.plugin.itest.MavenEmbeddedRuntime.initialize(M
avenEmbeddedRuntime.java:135)
at org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(TuscanyS
tartMojo.java:296)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Jan 11 13:14:43 EST 2007
[INFO] Final Memory: 6M/30M
[INFO]
C:\Tuscany\LousTestCases\testing\sca\itest\test-CallBackCType
Component Type file:
?xml version=1.0 encoding=ASCII?
componentType xmlns=http://www.osoa.org/xmlns/sca/1.0;
service name=CallBackCTypeService
interface.java
interface=org.apache.tuscany.sca.test.CallBackCTypeService
callbackInterface=org.apache.tuscany.sca.test.CallBackCTypeCallBack/
/service
/componentType
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL
[jira] Updated: (TUSCANY-1045) NPE caused by null Constructor Definition when using componentType side file
[
https://issues.apache.org/jira/browse/TUSCANY-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lou Amodeo updated TUSCANY-1045:
Attachment: test-CallBackCType.zip
NPE caused by null Constructor Definition when using componentType side file
-
Key: TUSCANY-1045
URL: https://issues.apache.org/jira/browse/TUSCANY-1045
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Reporter: Lou Amodeo
Attachments: test-CallBackCType.zip
r494421.The test-CallBackCType test is failing with a NPE. This test
case previously worked when using the workaround for Tuscany-967. It is
using a componentType side file to specify a callback interface shown below.
Problem appears that ctodDef is null.
// setup constructor injection
ConstructorDefinition? ctorDef = componentType.getConstructorDefinition();
java:120 Constructor? constr = ctorDef.getConstructor(); Constructor
Definition is null.
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.tuscany.core.implementation.java.JavaComponentBuilder.buil
d(JavaComponentBuilder.java:120)
at
org.apache.tuscany.core.implementation.java.JavaComponentBuilder.buil
d(JavaComponentBuilder.java:53)
at
org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegi
stryImpl.java:106)
at
org.apache.tuscany.core.implementation.composite.CompositeBuilder.bui
ld(CompositeBuilder.java:56)
at
org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegi
stryImpl.java:106)
at
org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java
:142)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav
a:97)
at
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl
(AbstractRuntime.java:148)
at
org.apache.tuscany.sca.plugin.itest.MavenEmbeddedRuntime.initialize(M
avenEmbeddedRuntime.java:135)
at
org.apache.tuscany.sca.plugin.itest.TuscanyStartMojo.execute(TuscanyS
tartMojo.java:296)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Jan 11 13:14:43 EST 2007
[INFO] Final Memory: 6M/30M
[INFO]
C:\Tuscany\LousTestCases\testing\sca\itest\test-CallBackCType
Component Type file:
?xml version=1.0 encoding=ASCII?
componentType xmlns=http://www.osoa.org/xmlns/sca/1.0;
service name=CallBackCTypeService
interface.java
interface=org.apache.tuscany.sca.test.CallBackCTypeService
callbackInterface=org.apache.tuscany.sca.test.CallBackCTypeCallBack/
/service
[jira] Created: (TUSCANY-1046) NPEO
NPEO Key: TUSCANY-1046 URL: https://issues.apache.org/jira/browse/TUSCANY-1046 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Reporter: Lou Amodeo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1046) NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION)
[ https://issues.apache.org/jira/browse/TUSCANY-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1046: Description: r494421 test-CallBackSetCallbackConv - This test attempts to use @Scope(CONVERSATION). Upon launch of test case using integration test environment the following NPE occurs. --- Test set: org.apache.tuscany.sca.test.CallBackSetCallbackConvITest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec FAILURE! testCallBackSetCallback(org.apache.tuscany.sca.test.CallBackSetCallbackConvITest) Time elapsed: 0.01 sec ERROR! java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:172) at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:760) at org.apache.tuscany.core.services.store.memory.MemoryStore.insertRecord(MemoryStore.java:110) at org.apache.tuscany.core.component.scope.ConversationalScopeContainer.getInstance(ConversationalScopeContainer.java:92) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:122) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:127) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:75) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy22.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvITest.testCallBackSetCallback(CallBackSetCallbackConvITest.java:12) Summary: NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION) (was: NPEO) NPE in MemoryStore.insertRecord() when @SCOPE(CONVERSATION) -- Key: TUSCANY-1046 URL: https://issues.apache.org/jira/browse/TUSCANY-1046 Project: Tuscany Issue Type: Bug Components: Java SCA Integration Tests Reporter: Lou Amodeo r494421 test-CallBackSetCallbackConv - This test attempts to use @Scope(CONVERSATION). Upon launch of test case using integration test environment the following NPE occurs. --- Test set: org.apache.tuscany.sca.test.CallBackSetCallbackConvITest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec FAILURE! testCallBackSetCallback(org.apache.tuscany.sca.test.CallBackSetCallbackConvITest) Time elapsed: 0.01 sec ERROR! java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:172) at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:760) at org.apache.tuscany.core.services.store.memory.MemoryStore.insertRecord(MemoryStore.java:110) at org.apache.tuscany.core.component.scope.ConversationalScopeContainer.getInstance(ConversationalScopeContainer.java:92) at org.apache.tuscany.core.implementation.PojoAtomicComponent.getTargetInstance(PojoAtomicComponent.java:122) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.getInstance(JavaTargetInvoker.java:127) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:75) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(TargetInvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(AbstractInboundInvocationHandler.java:45) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(JDKInboundInvocationHandler.java:122) at $Proxy22.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvITest.testCallBackSetCallback(CallBackSetCallbackConvITest.java:12) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-1047) Add Integration Test Cases for Callbacks and Conversations
[ https://issues.apache.org/jira/browse/TUSCANY-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1047: Attachment: CallBackandConversationITests.zip Add Integration Test Cases for Callbacks and Conversations -- Key: TUSCANY-1047 URL: https://issues.apache.org/jira/browse/TUSCANY-1047 Project: Tuscany Issue Type: Task Components: Java SCA Integration Tests Reporter: Lou Amodeo Attachments: CallBackandConversationITests.zip Please see attached Integration test cases for Callbacks and Conversations to be aded to the integration test suite. These test cases at this point all fail and have open JIRA's which will be linked to these test cases for reference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ doubts about Type.h
OK, there is no problem to keep it as an exception. But it would be easier
to code if it wasn't. I agree with leave it as an exception to explicity to
mean that it's an EXCEPTION.
I'm actually coding from DAS Java to DAS c++ and there is one part of the
code that requires to check if exists a property with a specified name. But
I can handle it with exception anyway ; ) Thanks
Adriano Crestani
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
Just one more thought. It comes down to how often you think the property
will not be found. returning a pointer (or even a re counting ptr object)
requires the user to ALWAYS code an if (xxx) following the getProperty.
This
is why the API is as it is today so that the normal use case is simple
for
the user.
I'd like to understand the use case where we are trying to do
Type::getProperty(propname) where you are not expecting propname to be a
property.
Cheers,
On 11/01/07, Yang ZHONG [EMAIL PROTECTED] wrote:
Agree, neither Property* nor Property tracks references.
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
Maybe the best solution would be to return a PropertyPtr (we do not
like
returning raw pointers to our internal data so this is better than
Property*
... avoids lifetime of the Pointee problems):
PropertyPtr x = myType-getProperty(ID);
if (x)
{
x-what_ever_it_is_you_want_to_do_with_the_property??
}
On 11/01/07, Pete Robbins [EMAIL PROTECTED] wrote:
The reason getProperty throws an exception is that it's a
exceptional
condition ;-)
The expectation is that you KNOW the names of the properties on the
SDO
that you are dealing with. If not, then you would use
getPropertyList
or
getInstanceProperties and iterate over the list.
I'm assuming in your case that ALL your DO's are expected to have a
particular property (ID)??. In which case isn't it an error if they
don't =
exception?
On 11/01/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I think it wouldn't be a good idea, because if you want to check
if
there is
a property with the specified name using hasProperty method and
later
to
get
the property with getProperty(string) it would look for the
property
name
twice in the property list, for example:
if (hasProperty(ID)) { // look on the list here
const Property t = getProperty(ID); // and here
}
The best way should be:
int propertyIndex = getPropertyIndex(ID);
if (propertyIndex != -1) { // if it hasn't been found
const Property t = getProperty(propertyIndex); // and here to
get
the
Property directly
}
However, if the method getPropertyIndex(string) doesn't find any
property
with the specified name it also throws a
SDOPropertyNotFoundException.
I
think we could purpose not a bool
Type::hasProperty(std::string propertyName) method, but a int
Type::getPropertyIndex(string) that returns a -1 value if the
property
name
is not found, instead of an exception.
Another question, where do I find the sdo spec?
Adriano Crestani
http://osoa.org/display/Main/Service+Data+Objects+Specifications
On 1/11/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 11/01/07, Adriano Crestani [EMAIL PROTECTED]
wrote:
Thanks Pete, I thought there would be an easier way to do
this.
But
if
you
say so, I think it's the only way. Thanks again!
That is what is in the spec. Maybe we could propose a bool
Type::hasProperty(std::string propertyName); method
Cheers,
Adriano Crestani
On 1/10/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 10/01/07, Adriano Crestani [EMAIL PROTECTED]
wrote:
I'm begginer with C++ and I have one doubt about the
function
defined
in
Type.h: virtual SDO_API const Property getProperty(const
char*
propertyName) const = 0. It's supposed to return a
reference
to a
Property
object that has the name equal to the parameter
propertyName,
but if
there
is no Property object with this name? What does this
function
return?
It would through a SDOPropertyNotFoundException.
I tried to do this...
if (type.getProperty (ID) == NULL)
...but as long as far as I know it's not possible. Is
there
a
way to
check
if the function has found Property object with the
specified
name or
not.
Adriano Crestani
There is no easy way to do this. You would need to wrap the
getProperty
in
a
try/catch block.
Cheers,
--
Pete
--
Pete
--
Pete
--
Pete
--
Yang ZHONG
--
Re: Anyone seeing this on the build ?
Yes, I see the same error, was wondering if it was just me as well. On 1/11/07, Luciano Resende [EMAIL PROTECTED] wrote: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugins Version: 8-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugins:pom:8-SNAPSHOT from the specified remote repositories: codehaus.org (http://snapshots.repository.codehaus.org/), central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshot (http://snapshots.repository.codehaus.org) [INFO] -- Luciano Resende http://people.apache.org/~lresende
[jira] Created: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO CTS] addition of paramatized tests, application server harness
I have opened *TUSCANY-1048https://issues.apache.org/jira/browse/TUSCANY-1048 * to track this topic. The initial drop of the cts code had some contributions from Brian Murray and myself. I have made some significant modifications to these which I hope will better fit into the framework. The work is not complete but is complete enough to get some feedback on what features etc would be desirable in the CTS. - Paramatized test suite. Tests API calls and scenarios using Junit 4.1paramatized test runner to use DataObjects created and populated using different mechanisms - Application Server Test harness and application. Application UI using DOJO to categorize and present errors within a jsp for tests that have been executed within the application server environement rather than within a simple standalone java env. - Use TestHelper which in turn used HelperProvider to get instance of commonj.sdo.helper.* classes. I will attach source to the JIRA and continue this discussion there where appropiate. Robbie On 1/11/07, Robbie Minshall [EMAIL PROTECTED] wrote: I would lean towards providing an exucutable jar file and a structure that allows for vendors to have their own branch/pom.xml for vendor specific implementations ( static code, TestHelperImpl etc ) and a dependancy on the cts ( java/cts/sdo21 java/cts/vendorImpl/tuscany or something). However, I am not sure off the top of my head if that would work well with the surefire plugin for maven. I personally prefer and use ant so will ultmately just be pulling in the cts jar into my own build env. Robbie On 1/9/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I would like to get people's thoughts on how we want to launch the SDO test suite. As you may have seen, an initial set of tests have been committed via jira 987 http://issues.apache.org/jira/browse/TUSCANY-987. Since the tests are the product of the CTS suite, they are in the /src/main/ folder. As I'm sure you know this means that they will be built into a jar when the default mvn build is run. Currently the pom does not actually attempt to run the CTS against any implementation. Personally I think this is the right default behaviour, if it was to run the CTS against Tuscany by default it would add a dependency to tuscany and download it - which kind of goes against the idea of being implementation agnostic. However, people obviously do need to execute the CTS against an implementation. We can do this a number of ways: 1. Provide commented out sections in the pom.xml that when uncommented would run against a given implementation (with Tuscany as an example) 2. Provide seperate, alternative pom's that run against given implementations; for example mvn -f tuscany.xml to run against Tuscany 3. Provide an executable jar that contains a launcher such that a java -jar sdo2.1-cts-1.0-SNAPSHOT.jar would execute the test suites (and leave it to the user to put an implementation on their classpath) 4. Provide a set of shell script to launch the tests (for Windows and unix/linux) My personal preference is 2 (and is seems easier than 3 4) but not sure if this approach would be acceptable for other implementations. Anyone got an opinion of how they would like to launch/execute the tests ? Cheers, Dan -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553 -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
[jira] Updated: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Minshall updated TUSCANY-1048: - Attachment: tuscany-1048-paramatizedTests1.zip SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Attachments: tuscany-1048-paramatizedTests1.zip An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1040) DAS C++
[ https://issues.apache.org/jira/browse/TUSCANY-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464022 ] Luciano Resende commented on TUSCANY-1040: -- Adriano, could you please reattach the initial drop of the C++ DAS, and select the radiobutton granting license to publish this to Tuscany project, this is the radiobutton right below from where you select the file to atach. DAS C++ --- Key: TUSCANY-1040 URL: https://issues.apache.org/jira/browse/TUSCANY-1040 Project: Tuscany Issue Type: New Feature Components: C++ SDO Affects Versions: Wish list Reporter: Luciano Resende Fix For: Wish list Attachments: DAS_CPP.zip, DAS_CPP_01_11_2007.zip Create a version of DAS in C++ integrating with SDO C++ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1048) SDO CTS. Contribute Paramatized Test Cases, and application server test harness
[ https://issues.apache.org/jira/browse/TUSCANY-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464024 ] Robbie Minshall commented on TUSCANY-1048: -- I have attached tuscany-1048-paramatizedTests1.zip This is a first attempt at converting Brian's and my test cases to a form more applicable to the cts. Please let me know what is good and what is bad. I have converted to the maven format though did not create a patch at this point becaues there is a lot of changes and I wanted some feedback before making this effort. - Created junit 4.1 paramatized tests rather than using the abstracted scenario method - Used TestHelper interface for non spec APIs ( this needs some improvement ) and for obtaining implementation specific helper classes etc. The DefaultTestHelper is not in this zip as I currently have it in a vendorSpecific subdirectory which I use for the tuscany implementation - Removed use of SDOUtil and INSTANCE for helper methods - Added @Suite Classes for paramatized and general tests - Made means and creation of population of DataObjects extendable by vendors ( good for using the same test cases for vendor specific static sdo etc ). I will add a seperate zip and screenshot for the application test harness. This is a simple servlet/jsp and junitCore modification which allows the user to execute test cases in application server environment and view results. It uses DOJO which may or may not be a problem. Since my use cases for SDO are based upon the execution of applications that use SDO within an application server this is very valuable to my testing but I am unsure whether or not the CTS will be interested. SDO CTS. Contribute Paramatized Test Cases, and application server test harness - Key: TUSCANY-1048 URL: https://issues.apache.org/jira/browse/TUSCANY-1048 Project: Tuscany Issue Type: Improvement Components: Java SDO Community Test Suite Reporter: Robbie Minshall Attachments: tuscany-1048-paramatizedTests1.zip An important attribute of sdo test cases is that the SDO APIs and scenarios work for DataObjects that are created and populated in different ways. This JIRA has been opened to contirbute - modification to 'scenarios' in initial cts drop to paramatized junit tests - Custom Junit Core and test application which facilitates the execution of test cases within an application server ( such as tomcat ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move Tuscany wiki to Apache CWIKI?
Hi, As the first step, I have filed a JIRA issue (https://issues.apache.org/jira/browse/INFRA-1107) to request to create a space for Tuscany on the CWIKI site. Once it's created, we can start to play with it and then decide if we should move. Thanks, Raymond - Original Message - From: Dan Murphy [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Sunday, January 07, 2007 3:51 PM Subject: Re: Move Tuscany wiki to Apache CWIKI? I like the idead of a single (wiki based) site; it would be better than having the current problem of overlap between wiki and website - as per the http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09447.htmlthread... If CXF have found it to work for them I think it would be a great plan On 06/01/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jim Marino wrote: On Jan 5, 2007, at 6:08 PM, Jeremy Boynes wrote: For quite a while the Confluence wiki was not maintained by ASF infrastructure - it was very much use at your own risk. There may be enough people using it now that that may have changed but it would be worth finding out. -- Jeremy On Jan 5, 2007, at 5:00 PM, Raymond Feng wrote: Hi, Tuscany wiki is currently hosted at http://wiki.apache.org/ws/Tuscany which is backed by MoinMoinWiki. I personally found it's not very productive to work this wiki. Recently I tried Confluence wiki and it seems to be more attractive: * Better look and feel and you can even customize the schemes * Easier to use, for example, CWIKI supports Rick Text editing in addtion to Wiki Markup * Export to PDF/word/HTML * Comments * And more ... Apache has a CWIKI set up @ http://cwiki.apache.org/confluence. You can see more details at http://cwiki.apache.org/confluence/display/CWIKI/Index. Quite a few projects use it to maintain their web sites and documentations. Should we request a space for Tuscany and migrate our existing contents over? We can take this chance to better organize our materials. Thanks, Raymond I'd be in favor of this given Jeremy's point above. Perhaps we could use CXF as a template to do this since it is very clean and nicely organized? http://cwiki.apache.org/CXF/ Jim +1 On a related note the CXF approach resolves the constant dilemma between 'Project home page' and 'Wiki', as their home page is a Wiki! It would be worth asking them what they think about the approach they've taken and if they're happy with it and recommend it to others. Thoughts? -- 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]
[jira] Assigned: (TUSCANY-1047) Add Integration Test Cases for Callbacks and Conversations
[ https://issues.apache.org/jira/browse/TUSCANY-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1047: - Assignee: Raymond Feng Add Integration Test Cases for Callbacks and Conversations -- Key: TUSCANY-1047 URL: https://issues.apache.org/jira/browse/TUSCANY-1047 Project: Tuscany Issue Type: Task Components: Java SCA Integration Tests Reporter: Lou Amodeo Assigned To: Raymond Feng Attachments: CallBackandConversationITests.zip Please see attached Integration test cases for Callbacks and Conversations to be aded to the integration test suite. These test cases at this point all fail and have open JIRA's which will be linked to these test cases for reference. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DAS C++ needing volunteers and advises
[snip] Pete Robbins wrote: On 09/01/07, Luciano Resende [EMAIL PROTECTED] wrote: To get more people helping on this I was wondering if we should add the code to the trunk, where more people would have access to review and contribute to the code. Could you guys advise me where is best for me to place this initial code (non working at the moment) ? Should it go to my sandbox ? Or I could place it under someplace inside the cpp sdo directory in trunk, but leave it out of the main build ? I think this should be kept separate from SDO. I would put it undert tuscany/cpp/das +1, I think it makes sense to create a new directory under tuscany/cpp for this. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1049) Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options
Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options - Key: TUSCANY-1049 URL: https://issues.apache.org/jira/browse/TUSCANY-1049 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Yang ZHONG Fix For: Java-Mx Currently, XMLStreamHelper#loadObject only supports qualified/global elements, because Type is required to parse XML. However, Type may also be available for unqualified/local elements such as xsi:type and user input. I'm working on Change Summary StAX deserializing, which needs to load deleted Data Objects. Thanks to Frank for recommending XMLStreamHelper#loadObject. However, the elements may be unqualified/local which may have xsi:type and I know the Type even if no xsi:type. I'm attaching the prototype to enable XMLStreamHelper#loadObject for unqualified/local elements. It enables XMLStreamHelper#loadObject XMLDocumentImpl#load for options BTW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Heads-up - changing CompositeContext interface, was: CompositeContext method names
Raymond Feng wrote: Hi, You first need to configure the ssh in user.home/.m2/settings.xml with the following content: ?xml version=1.0 encoding=UTF-8? settings servers server idapache.snapshots/id usernameyour_apache_id/username !-- Default value is ~/.ssh/id_dsa -- privateKeyuser.home\.ssh\id_dsa/privateKey passphraseyour_password/passphrase /server /servers /settings Then you can run mvn deploy under the modules to upload the SNAPSHOT version of the artifact. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, January 11, 2007 8:52 AM Subject: Re: CompositeContext method names Jeremy Boynes wrote: Can't be sure without seeing the changes - including a patch would be helpful. In general, this sounds like an incompatible change (it's renaming methods) so republishing the snapshots would be a good move. If it was a less intrusive change (e.g. adding a method) then just committing would be enough. -- Jeremy On Jan 10, 2007, at 5:56 PM, Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Jim Marino wrote: On Jan 8, 2007, at 4:26 PM, Jean-Sebastien Delfino wrote: The names of some of the methods on org.osoa.sca.CompositeContext do not match the API described in the 0.95 Java SCA CI specification (this was reported as http://issues.apache.org/jira/browse/TUSCANY-909). I have checked the latest SCA spec docs and the spec mailing lists and could not find any indication that the names on our definition of CompositeContext are the correct ones. I'm planning on making the following changes: - rename getCompositeName() to getName() - rename getCompositeURI() to getURI() Jim, you've been following this more closely than me, is this the right change? are the spec documents up to date and our code needs to be adjusted? or is it the other way around? Those have not changed to my knowledge (or at least I can't remember), so it is probably a simple oversight on our part. There are a number of changes where the spec needs to be updated in other areas (e.g. scopes), that I'm in the process of doing now. Jim Thanks, --Jean-Sebastien OK thanks! I'll make the code match the spec then :) I have the changes ready, affecting CompositeContext in the spec/sca project and 3 other classes in kernel. What is the best way to apply the changes? Is committing the spec and kernel changes sufficient? or do I need to republish the spec and kernel snapshots? Thanks, --Jean-Sebastien I have attached a patch to JIRA TUSCANY-909. The change is trivial, except for the fact that it affects two different modules, spec and kernel. Could somebody post here how to republish the snapshots and I'll try to do it. Thanks. -- Jean-Sebastien Thanks Raymond, This is a heads-up that I'm going to commit the changes in the patch attached to JIRA http://issues.apache.org/jira/browse/TUSCANY-909 and republish sca-api-r0.95-1.0-incubator-SNAPSHOT.jar and core-1.0-incubator-SNAPSHOT.jar to incorporate these changes. CompositeContext.getCompositeName() will be renamed to CompositeContext.getName() CompositeContext.getCompositeURI() will be renamed to CompositeContext.getURI() This will bring CompositeContext in line with the SCA Java CI specification 0.95. A build of tuscany/java with the all profile did not report any error, but I am sending this heads-up as this is a potentially breaking interface change. If there's no objection I will apply the changes and republish the snapshots tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1049) Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options
[ https://issues.apache.org/jira/browse/TUSCANY-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang ZHONG updated TUSCANY-1049: Attachment: prototype.1049 Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options - Key: TUSCANY-1049 URL: https://issues.apache.org/jira/browse/TUSCANY-1049 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Yang ZHONG Fix For: Java-Mx Attachments: prototype.1049 Currently, XMLStreamHelper#loadObject only supports qualified/global elements, because Type is required to parse XML. However, Type may also be available for unqualified/local elements such as xsi:type and user input. I'm working on Change Summary StAX deserializing, which needs to load deleted Data Objects. Thanks to Frank for recommending XMLStreamHelper#loadObject. However, the elements may be unqualified/local which may have xsi:type and I know the Type even if no xsi:type. I'm attaching the prototype to enable XMLStreamHelper#loadObject for unqualified/local elements. It enables XMLStreamHelper#loadObject XMLDocumentImpl#load for options BTW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Environment: n/a Reporter: David T. Adcox Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1050: Attachment: TUSCANY1050.xsd For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Environment: n/a Reporter: David T. Adcox Attachments: TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1050: Attachment: TUSCANY1050.patch For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Environment: n/a Reporter: David T. Adcox Attachments: TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1050) For some schemas, the code generated will not compile (notication and settable problems)
[ https://issues.apache.org/jira/browse/TUSCANY-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464069 ] David T. Adcox commented on TUSCANY-1050: - I've attached a patch file to address this issue. One item of note is that the patch includes patches for both the tools component and the impl component. For some schemas, the code generated will not compile (notication and settable problems) Key: TUSCANY-1050 URL: https://issues.apache.org/jira/browse/TUSCANY-1050 Project: Tuscany Issue Type: Bug Environment: n/a Reporter: David T. Adcox Attachments: TUSCANY1050.patch, TUSCANY1050.xsd Using the attached, test schema, the code generated with xsd2JavaGenerator will not compile. There still seems to be some EMF code being pulled into the generated class files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-917) XMLHelper.load() should demand-create global properties not defined in the SDO type system
[ https://issues.apache.org/jira/browse/TUSCANY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464071 ] Yang ZHONG commented on TUSCANY-917: http://issues.apache.org/jira/browse/TUSCANY-1049 may enable loading non-defined global properties without demand-creating which might not be all users' desire, assuming XMLHelper.save() has generated xsi:type for non-defined global properties. XMLHelper.load() should demand-create global properties not defined in the SDO type system -- Key: TUSCANY-917 URL: https://issues.apache.org/jira/browse/TUSCANY-917 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Currently, when you invoke XMLHelper.save(), it would serialize the non-defined global properties. However, the doc cannot be deserialized by XMLHelper.load() method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1049) Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options
[ https://issues.apache.org/jira/browse/TUSCANY-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464074 ] Yang ZHONG commented on TUSCANY-1049: - This improvement may help http://issues.apache.org/jira/browse/TUSCANY-917 without the side effect of demand-creating non-defined global properties. Enable XMLStreamHelper#loadObject for unqualified/local elements and BTW enable XMLStreamHelper#loadObject XMLDocumentImpl#load for options - Key: TUSCANY-1049 URL: https://issues.apache.org/jira/browse/TUSCANY-1049 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Yang ZHONG Fix For: Java-Mx Attachments: prototype.1049 Currently, XMLStreamHelper#loadObject only supports qualified/global elements, because Type is required to parse XML. However, Type may also be available for unqualified/local elements such as xsi:type and user input. I'm working on Change Summary StAX deserializing, which needs to load deleted Data Objects. Thanks to Frank for recommending XMLStreamHelper#loadObject. However, the elements may be unqualified/local which may have xsi:type and I know the Type even if no xsi:type. I'm attaching the prototype to enable XMLStreamHelper#loadObject for unqualified/local elements. It enables XMLStreamHelper#loadObject XMLDocumentImpl#load for options BTW. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (TUSCANY-1038) SDO databinding for Axis2
Hi Anthony, Thanks. I will keep you updated on the progress. Regards, Angel On 1/11/07, ant elder [EMAIL PROTECTED] wrote: Its great you'd like to contribute! Unfortunately you can't get Apache SVN access until you're a committer so for now you have to submit patches. Maybe as a start I should set up a sandbox directory for this with a template project structure and you and anyone else could submit patches against that until its in a fit state to ask to put into the Axis2 trunk. Thats just a suggestion say if you've a better approach or anyone else leap in with suggetsions. Just to summarize whats been said earlier about Axis2 databindings: - theres a good article at: http://wso2.org/library/35 - Axis2 has exsiting databindings for adb, jibx and xmlbeans so that code can be used as a guide: https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/jibx/ https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/adb/ https://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/xmlbeans/ - to get the new databinding jar picked up it has to be in the Axis classpath and the codegen-config.properties needs to be updated, see: http://svn.apache.org/repos/asf/webservices/axis2/trunk/java/modules/codegen/src/org/apache/axis2/wsdl/codegen/codegen-config.properties (this is in the axis2-codegen-1.1.jar in the Axis2 lib directory) - There's existing code that shows how to convert between Axiom OMElements and SDO DataObjects in the Tuscany DataBinding projects. The main classes are: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/databinding/databinding-sdo/src/main/java/org/apache/tuscany/databinding/sdo/DataObject2XMLStreamReader.java https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/databinding/databinding-sdo/src/main/java/org/apache/tuscany/databinding/sdo/XMLStreamReader2DataObject.java https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/databinding/databinding-axiom/src/main/java/org/apache/tuscany/databinding/axiom/OMElement2XMLStreamReader.java https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/databinding/databinding-axiom/src/main/java/org/apache/tuscany/databinding/axiom/XMLStreamReader2OMElement.java HTH, ...ant On 1/11/07, Angel Todorov [EMAIL PROTECTED] wrote: Hi Raymond, Yes the SDO binding would be definitely nice to have. I am willing to contribute along with you and any other guys who might be interested. Please inform me about what next steps that need to be taken and who is going to participate (do i have to create/ obtain some SVN account anywhere) ? Thanks Angel On 1/9/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Angel. I have been thinking about the approach for a while. There are also some discussions on the Axis2 ML. As you explained, it seems that it's fairly straightforward to implement a SDO binding for Axis2 and we can leverage it in Tuscany. FYI, we already have the fromOM() and toOM() runtime support for SDO using StAX XMLStreamReader. So it could be just a matter of developing a XSLT template and some code-gen utility methods. Are you interested in contributing to this feature? Ant and I will be happy to work with you. Thanks, Raymond - Original Message - From: Angel Todorov [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Cc: axis-dev@ws.apache.org Sent: Tuesday, January 09, 2007 8:05 AM Subject: Re: [jira] Created: (TUSCANY-1038) SDO databinding for Axis2 Hi Anthony, Hm... i was thinking - wouldn't it be possible to just modify (or create a new ) XLS template for Axis2 databinding extension. As far as I see, the emitter instance takes the template and the generated XML model from memory and emits out code (stubs, skeletons, MessageReceiver whatever). Since SDO is transparent to the actual Java - XML mapping, we can take any of the JiBX, JAXB, XMLBeans or ADB extensions, and use their Extension and Codegen Utility classes, and just modify the XLS template (i.e fromOM(..), toOM(..), etc. parts). Of course, this also assumes that we are bound to the above binding framework's XSD support, in case some provider has written their own SDO XML binding. What do you think ? Regards, Angel On 1/9/07, ant elder (JIRA) tuscany-dev@ws.apache.org wrote: SDO databinding for Axis2 - Key: TUSCANY-1038 URL: https://issues.apache.org/jira/browse/TUSCANY-1038 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: ant elder Fix For: Java-SDO-Mx Implement a native Axis2 databinding for SDO. Axis2 supports pluggable databindings and currently has support for things like xmlbeans, jibx, and Axis2s own ADB. It would
