Re: Sandbox build broken
On 6/26/06, Kenneth Tam [EMAIL PROTECTED] wrote: The sandbox build is broken right now (looks like issues around switching to a sandbox version of the spec project). Rather than risk adding to the confusion with another couple of checkins that I can't validate, I'm going to hold off until this gets fixed. I've just checked in a tidy up of the sandbox build that should allow it to run on a clean machine. I've tested by removing all tuscany and org.osoa artifacts from my local repo but didn't wipe it totally or remove the plugins. Please let me know if it is building for you or if there are other issues. I set the version id to 1.0-sandbox-SNAPSHOT to avoid conflicts with trunk. I also set it up to inherit version info as much as possible. I've disabled the checkstyle stuff for now - I will be adding it back in soon. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating multiple / smaller SPI projects
On Jun 26, 2006, at 4:20 PM, Jeremy Boynes wrote: On 6/26/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Here are a few thoughts and questions on our SPI story. I'd like to start a discussion on these items and get your thoughts. Cool. My first thought is that what you're describing here is very close to what we have in the sandbox - for example, common themes of modularity and removing complexity. I've added a few more detailed comments inline. We also tried to do this in terms of separating out various runtime capabilities as well. For example, Raymond's databinding approach could be a system service that is plugged into the core. The idea is the core performs a very limited set of specific tasks and the rest are delegated to extensions. Right now we have around 8,500+ lines of code in core. It would be great if we could limit it to say (arbitrarily) 25,000 lines max. A. I think we should create different projects for the various types of SPI we have, for example one project for the assembly model SPI, one project for the interaction/invocation related SPI, one project for the deployment SPI, one for the management SPI etc. This sounds good, especially when we deal with high level building blocks like management. One thing I think we need to be careful of though is breaking it down too far so that we force users to understand several different modules just to do something simple. I think we can address that with the right package structure in each module. One thing is we may be able to change the SPI packages around to improve clarity but I agree we have to pick the right level of granularity for our project structure. If these SPI go into a spec at some point this will allow us to publish them and evolve them independently. Agreed. We are actually leading the spec here which gives us a chance to influence the direction it is taking. However, when the spec actually adopts something the classes will move from the o.a.t namespace to the org.osoa one which will impact users and implementations. We can handle those changes for both separate modules and individual packages within a module. I also think that this allows to cut complexity, for example a contributor only interested in management will not get the other SPIs. More generally, somebody assembling/embedding a Tuscany runtime will be in a better position to pick a subset of selected pieces. Cutting complexity is good and we can help with that by making sure that things that naturally go together are bundled together. For example, someone writing an extension should not need to dig through several modules to figure out what they need to do. Finally this shows a clear path to people who want to extend the runtime, for example, if we put the java interface support in a different project, the WSDL interface support in another one, then somebody wanting to add ruby or javascript support will have a clear template to follow. I'm not sure what you mean here. This sounds like two implementations of a pluggable interface type SPI - one for Java interfaces, one for WSDL ones - which I think would be a good way to break this down. B. I'd like to separate interfaces and implementation classes or helpers in different projects. Wholeheartedly agree on the separation between interface and implementation. In M1 we did this but had both inside the same module which was confusing; one of the things we did in the sandbox was to move the interfaces into spi and leave the implementation in core. I think helpers can go either way. If they are useful (but optional) to any implementation of the interface, then we can reduce the complexity by including them with the SPI. An example of this would be the extension base classes that contain functionality to support an implementation but which (in general) don't implement the interface contracts. On the other hand, classes that support a specific implementation should just be part of it (directly or in the form of a library). For example the assembly model interfaces would go into one project, the Tuscany implementation of these interfaces in a different one. In M1 we have interfaces+implementation classes but they are in the same project, in the sandbox there's no interfaces anymore for this, can you guys tell me what motivated that change? Simplicity really. The model objects are really just data holders (set and get methods only) and don't contain significant implementation. Separate interfaces and implementation classes will allow us to swap different implementations (e.g. using different databindings, or integrated with tooling for example). It will also allow model extensions to not depend on Tuscany implementations classes (the extensions will only implement interfaces instead of extending implementation classes). C. I would like to change the project folder structure a little and introduce a plugins/ directory where contributors could
Re: SCA in OSGi - was SCA Spec Update and Recursive Core presentation
Yea that was my bad. Jeremy just cleaned it up so if you can sync that would work better. I imagine you are going to run into many sharp objects but since you mountain bike I imagine you're used to it :-). What is in the OSGi project is really bare bones. Jeremy and Rick are having an ongoing deployer discussion and I think it would be good to link up with them on the list since I think that will help bootstrap in Equinox. I'm generally around so when you run into questions, feel free to post them and we can work through the issues. Jim On Jun 26, 2006, at 11:43 AM, Hawkins, Joel wrote: Found the spec directory - never mind! -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Monday, June 26, 2006 1:54 PM To: tuscany-dev@ws.apache.org Subject: SCA in OSGi - was SCA Spec Update and Recursive Core presentation Turn about is fair play - just got back from vacation myself - 6 days of cycling in the Rockies. :-) I think this approach will work well for me. I've done an update on the sandbox code and am having troubles building. It appears that the sca-api jar has been updated with some new classes (org.osoa.sca.CompositeContext, for example), but the SNAPSHOT available to Maven hasn't been. Am I catching the code in an in between state? Any hints would be appreciated! My goal for the week is to get the simple composite example working, using the deployment you describe below. I'm sure I'll bump into lots of sharp objects, which will generate lots of questions. Looking forward to the journey. Cheers, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Sunday, June 18, 2006 3:58 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Sorry for the delay, I've been on vacation... On Jun 13, 2006, at 6:54 AM, Hawkins, Joel wrote: Hi Jim, My personal interest is in SCA-OSGi integration. I listened to your presentation on the new core architecture, and am going through the sandbox code trying to gain some understanding of how it all hangs together. I'd really like to be involved in this area, and would appreciate any suggestions you can make. That would be great. I checked in a skeleton OSGi project that uses Equinox. There are a number of items that we need to figure out, including: - The details on OSGi as a host environment. I was thinking the root runtime context would be loaded in an OSGi and registered as an OSGi service. Application composites (e.g. applications contributed from end users) would be loaded as separate bundles and they would reference the SCA OSGi service to register themselves with the Tuscany runtime. Likewise, system composites would register themselves in a similar way. - Related to the first point, deployment structure. I'd like to see us figure out specifics concerning the deployment process such as run levels - How to access OSGi services. I was thinking there would be an OSGi binding. The easiest way to proceed may be for you to start posting questions as you work through looking at how the sandbox code works. Once we do that, we can move to specifics on how to integrate with OSGi. Does that work for you? I've got a separate thread going with Jervis around the management capabilities. We (the Corona team) are currently working on a WSDM interface for the OSGi runtime - I would hope that the lessons learned would be directly applicable to a WSDM interface for SCA. O.K. that's great Thanks, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 4:38 PM To: tuscany-dev@ws.apache.org Subject: Re: Subject: SCA Spec Update and Recursive Core presentation Hi Joel, Great. Do you have some specific areas you are interested in working on w.r.t to Tuscany? I started a skeleton project of getting Tuscany to deploy into Equinox. Also, there has been a thread on providing management capabilities for Tuscany (Jervis I beleive was looking into this). We can definitely use help in these areas as well as the other areas we outlined in the June 9 message from this same thread. Let me know and I can point you at things in more detail. Jim On Jun 12, 2006, at 6:24 AM, Hawkins, Joel wrote: Jim, My name is Joel Hawkins, and I'm working with the Apache Muse project on porting the IBM contribution for the new version of Muse to OSGi. I'm also working on a recently formed Eclipse project (the Corona project) - which has a goal of providing a manageable (using Muse's WSDM implementation) SCA-type environment (hopefully using Tuscany) for Eclipse. I've been following the Tuscany project for some time, and after sitting through the presentation of the latest spec update, I believe SCA has a very important role to play in moving OSGi's Declarative Services spec forward, and I'd be very interested in helping out in these areas. Cheers, Joel Hawkins -Original Message- From: Jim
Re: Making invokers/interceptors actual components
On Jun 26, 2006, at 5:10 PM, Jean-Sebastien Delfino wrote: I'm looking at the Invoker/interceptor contribution mechanism and I'd like to propose to make them actual components. Currently an interceptor is not a component, it's an object added to an invocation chain by a Builder component. I think that if an invoker or interceptor could just be a component then we would have a better continuity in terms of programming model between application components, mediation components, components implementing various business or system policies and interceptor components contributing runtime behavior. That's a good idea and kind of what we presumed in the core2 extension model. Basically, an interceptor can be something newed up by the builder or autowired as a component to it. I think it is a matter of individual style but (e.g. some interceptors do not need the overhead of being a component), as you said, having it as a component makes it open to management and monitoring. I'd like to make sure, though, we mention both ways are valid. Any 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]
Re: Sandbox build broken
On 6/26/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I've disabled the checkstyle stuff for now - I will be adding it back in soon. It's now back in as part of a sourcecheck profile $ mvn -Psourcecheck -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic change for SDO Types
I can speak for the Tuscany C++ implementation. In this version the data factory keeps a record of all types and their properties. When the first data object is created, the metadata becomes read-only, and properties can no longer be added to types. The only way to add dynamic content to a type is to declare it as an open type - in which case you can add any properties you like, but they apply only to the instance which you are working with, and are not known to the metadata. getInstanceProperties gives you the list of all metadata properties plus all the open ones, whilst getType().getProperties() gives only the properties defined on the metadata. regards, Ed. On 26/06/06, sensystems [EMAIL PROTECTED] wrote: Hello I have a conceptual question with SDO, may be you can help me to figure this out: As the dynamic DataObject will always use reflection APIs The questions are: 1) Are there APIs which allow you to change a Type? 2) If so, what's the synchronization between the type and instance my requirements says this: a) I should provide the aplication with an initial base metamodel. b) the users (using the gui)can make instances of that metamodel c) the users can add propertyes to any type d) the users can only remove the properties they added e) if a property is added to a type, the current instances should have that property set to the default value (or may be unset) d) if a property is removed from a type all the instances should have that property removed Thank you very much for your responses. sensystems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-471) Crash when 2 WS EntryPoint services with different System Root paths are accessed
[ http://issues.apache.org/jira/browse/TUSCANY-471?page=all ] Andrew Borley updated TUSCANY-471: -- Attachment: TUSCANY-471.patch This patch uses a singleton pattern to keep a single EntryPointProxy object (containing a single TuscanyRuntime object). When a new WS request comes in, the SystemRoot Module/EntryPoint strings are compared - if different, TuscanyRuntime is stopped, changed and restarted - if the same, TuscanyRuntime is left unaltered. Crash when 2 WS EntryPoint services with different System Root paths are accessed - Key: TUSCANY-471 URL: http://issues.apache.org/jira/browse/TUSCANY-471 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Attachments: TUSCANY-471.patch I have 2 WS EntryPoint services deployed to the same axis2c server, each with a different System Root path defined. The first starts and runs fine but the second causes a crash with an EntryPointNotFoundException. I'm not sure this is an allowed scenario at the moment anyway - does the runtime currently support changes of System Root? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-484) Attribute groups only working if defined in the default namespace
[
http://issues.apache.org/jira/browse/TUSCANY-484?page=comments#action_12417989
]
Pete Robbins commented on TUSCANY-484:
--
This is caused by the schema parser treating the nam= attribute as a qname when
it is not. Patch:
Index: commonj/sdo/SDOSchemaSAX2Parser.cpp
===
--- commonj/sdo/SDOSchemaSAX2Parser.cpp (revision 415278)
+++ commonj/sdo/SDOSchemaSAX2Parser.cpp (working copy)
@@ -251,18 +251,8 @@
{
if
(attributes[i].getName().equalsIgnoreCase(name))
{
-XMLQName qname(attributes[i].getValue(),
-schemaInfo.getSchemaNamespaces(),
-namespaces);
-if (qname.getURI().isNull())
-{
-currentGroup-uri =
schemaInfo.getTargetNamespaceURI();
-}
-else
-{
-currentGroup-uri = qname.getURI();
-}
-currentGroup-name = qname.getLocalName();
+currentGroup-uri =
schemaInfo.getTargetNamespaceURI();
+currentGroup-name = attributes[i].getValue();
}
}
}
Attribute groups only working if defined in the default namespace
-
Key: TUSCANY-484
URL: http://issues.apache.org/jira/browse/TUSCANY-484
Project: Tuscany
Type: Bug
Components: C++ SDO
Versions: Cpp-current
Environment: Windows
Reporter: Graham Charters
When loading the following schema I get a parse error Use of undefined group
commonAttributes.
?xml version=1.0 encoding=utf-8 ?
schema targetNamespace=http://example.org;
xmlns:ns1=http://example.org; xmlns=http://www.w3.org/2001/XMLSchema;
attributeGroup name=commonAttributes
attribute name=attr1 type=string /
attribute name=attr2 type=string /
/attributeGroup
complexType name=extendedStringType
sequence
element name=el1 type=string /
element name=el2 type=string /
/sequence
attributeGroup ref=ns1:commonAttributes/
/complexType
/schema
It appears that if I change the schema so that the group is defined in the
default namespace for the schema, then the parse works. So the following
schema does not produce the error.
?xml version=1.0 encoding=utf-8 ?
xs:schema targetNamespace=http://example.org;
xmlns=http://example.org; xmlns:xs=http://www.w3.org/2001/XMLSchema;
xs:attributeGroup name=commonAttributes
xs:attribute name=attr1 type=xs:string /
xs:attribute name=attr2 type=xs:string /
/xs:attributeGroup
xs:complexType name=extendedStringType
xs:sequence
xs:element name=el1 type=xs:string /
xs:element name=el2 type=xs:string /
/xs:sequence
xs:attributeGroup ref=commonAttributes/
/xs:complexType
/xs:schema
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://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] Updated: (TUSCANY-471) Crash when 2 WS EntryPoint services with different System Root paths are accessed
Sounds good. I'll give it a go. On 27/06/06, Andrew Borley (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-471?page=all ] Andrew Borley updated TUSCANY-471: -- Attachment: TUSCANY-471.patch This patch uses a singleton pattern to keep a single EntryPointProxy object (containing a single TuscanyRuntime object). When a new WS request comes in, the SystemRoot Module/EntryPoint strings are compared - if different, TuscanyRuntime is stopped, changed and restarted - if the same, TuscanyRuntime is left unaltered. Crash when 2 WS EntryPoint services with different System Root paths are accessed - Key: TUSCANY-471 URL: http://issues.apache.org/jira/browse/TUSCANY-471 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Attachments: TUSCANY-471.patch I have 2 WS EntryPoint services deployed to the same axis2c server, each with a different System Root path defined. The first starts and runs fine but the second causes a crash with an EntryPointNotFoundException. I'm not sure this is an allowed scenario at the moment anyway - does the runtime currently support changes of System Root? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] -- Pete
Re: [jira] Updated: (TUSCANY-471) Crash when 2 WS EntryPoint services with different System Root paths are accessed
Works a treat. Patch is checked in. Thanks On 27/06/06, Pete Robbins [EMAIL PROTECTED] wrote: Sounds good. I'll give it a go. On 27/06/06, Andrew Borley (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-471?page=all ] Andrew Borley updated TUSCANY-471: -- Attachment: TUSCANY-471.patch This patch uses a singleton pattern to keep a single EntryPointProxy object (containing a single TuscanyRuntime object). When a new WS request comes in, the SystemRoot Module/EntryPoint strings are compared - if different, TuscanyRuntime is stopped, changed and restarted - if the same, TuscanyRuntime is left unaltered. Crash when 2 WS EntryPoint services with different System Root paths are accessed - Key: TUSCANY-471 URL: http://issues.apache.org/jira/browse/TUSCANY-471 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Attachments: TUSCANY-471.patch I have 2 WS EntryPoint services deployed to the same axis2c server, each with a different System Root path defined. The first starts and runs fine but the second causes a crash with an EntryPointNotFoundException. I'm not sure this is an allowed scenario at the moment anyway - does the runtime currently support changes of System Root? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] -- Pete -- Pete
[jira] Created: (TUSCANY-498) FAQ entry: MSVC 7 tries to generate stubs for WSDL files
FAQ entry: MSVC 7 tries to generate stubs for WSDL files Key: TUSCANY-498 URL: http://issues.apache.org/jira/browse/TUSCANY-498 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Environment: Windows XP MSVC7 Reporter: Simon Laws Priority: Trivial If you receive a stub generation error when trying to build CPP project files then - select each WSDL file in the project - right click and select properties - change Excluded from build to yes - I found I also had to change the tool setting to anything other than Web Service Proxy Generator to turn proxy generation off but I don't know why I had to do this. I would expect the previous step to have turned it off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-499) FAQ entry or better error message: Missing DLLs cause
FAQ entry or better error message: Missing DLLs cause -- Key: TUSCANY-499 URL: http://issues.apache.org/jira/browse/TUSCANY-499 Project: Tuscany Type: Improvement Components: C++ SCA Environment: Windows XP Reporter: Simon Laws Priority: Trivial When running the Axis2 stangalone container you get a cryptic error message (below) if the SCA or SDO dll's are not on the path. Here is the script I use to run the server with with... set TUSCANY_SCACPP_LOGGING=9 set PATH=tuscany\cpp\sca\deploy\bin;tuscany\cpp\sdo\deploy\bin;axis2c-bin-0.92-win32\lib;libxml2-2.6.23.win32\bin;iconv-1.9.1.win32\bin;zlib-1.2.3.win32\bin cd axis2c-bin-0.92-win32\bin axis2_http_server.exe -l 4 Here is the error you get it the SCA and/or SDO dll's are missing [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\engine.c(881) Invoking phase Dispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler addressing_based_dispatcher within the phase Dispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\addr_disp.c(110) Checking for service using WSA enpoint address : http://127.0.0.1:9090/axis2/services/Calculator [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\addr_disp.c(140) Service found using WSA enpoint address [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler request_uri_based_dispatcher within the phase Dispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler soap_action_based_dispatcher within the phase Dispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler soap_message_body_based_dispatcher within the phase Dispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\soap_body_disp.c(211) Checking for operation using SOAP message body's first child's local name : add [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\soap_body_disp.c(220) Operation found using SOAP message body's first child's local name [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\engine.c(881) Invoking phase PostDispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler dispatch_post_conditions_evaluator within the phase PostDispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler context_handler within the phase PostDispatch [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\engine.c(881) Invoking phase PolicyDetermination [Fri Jun 23 13:44:36 2006] [debug] ..\..\modules\core\engine\engine.c(881) Invoking phase PreDispatch [Fri Jun 23 13:44:37 2006] [error] ..\..\modules\core\receivers\raw_xml_in_out_msg_recv.c(99) Impl object for service not set in message receiver 94 :: Failed in creating DLL [Fri Jun 23 13:44:37 2006] [debug] ..\..\modules\core\engine\engine.c(440) Axis2 engine receive successful [Fri Jun 23 13:44:37 2006] [debug] ..\..\modules\core\engine\engine.c(881) Invoking phase MessageOut [Fri Jun 23 13:44:37 2006] [debug] ..\..\modules\core\engine\phase.c(338) Invoke the handler AddressingOutHandler within the phase MessageOut [Fri Jun 23 13:44:37 2006] [warning] ..\..\modules\core\transport\http\receiver\http_svr_thread.c(336) Error occured in processing request -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-501) Crash on SDOTypeNotFound exception
Crash on SDOTypeNotFound exception -- Key: TUSCANY-501 URL: http://issues.apache.org/jira/browse/TUSCANY-501 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws When SDOTypeNotFound is thrown the runtime crashes rather than reporting the error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-500) Failure on use of croncrete complex types in WSDL
Failure on use of croncrete complex types in WSDL -- Key: TUSCANY-500 URL: http://issues.apache.org/jira/browse/TUSCANY-500 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Environment: Windows XP Reporter: Simon Laws There is something strange happeing in the WSDL based registration of types. When I use an annonymous concrete types in the Big Bank sample, for example xsd:element name=getAccountReport xsd:complexType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:element ... xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=tns:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element The types that are registered are... Type: commonj.sdo#BigDecimal Type: commonj.sdo#BigInteger Type: commonj.sdo#Boolean Type: commonj.sdo#Byte Type: commonj.sdo#Bytes Type: commonj.sdo#ChangeSummary Type: commonj.sdo#Character Type: commonj.sdo#DataObject Type: commonj.sdo#Date Type: commonj.sdo#Double Type: commonj.sdo#Float Type: commonj.sdo#Integer Type: commonj.sdo#Long Type: commonj.sdo#OpenDataObject Type: commonj.sdo#Short Type: commonj.sdo#String Type: commonj.sdo#URI Type: http://www.bigbank.com/AccountService#AccountReport Property: checking type: http://www.bigbank.com/AccountService#CheckingA ccount Property: savings type: http://www.bigbank.com/AccountService#SavingsAcc ount Property: stocks type: http://www.bigbank.com/AccountService#StockAccoun t Type: http://www.bigbank.com/AccountService#CheckingAccount Property: accountNumber type: commonj.sdo#String Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#RootType Property: getAccountReport type: http://www.bigbank.com/AccountService#g etAccountReport Property: getAccountReportResponse type: http://www.bigbank.com/AccountS ervice#getAccountReportResponse Type: http://www.bigbank.com/AccountService#SavingsAccount Property: accountNumber type: commonj.sdo#String Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#StockAccount Property: accountNumber type: commonj.sdo#String Property: symbol type: commonj.sdo#String Property: quantity type: commonj.sdo#Integer Property: balance type: commonj.sdo#Float Type: http://www.bigbank.com/AccountService#customerID Property: customerID type: commonj.sdo#String Type: http://www.bigbank.com/AccountService#getAccountReport Property: customerID type: http://www.bigbank.com/AccountService#custome rID Type: http://www.bigbank.com/AccountService#getAccountReportResponse Property: accountReport type: http://www.bigbank.com/AccountService#Acco untReport Type: http://www.quickstockquote.com/StockQuoteService/#RootType Property: getQuote type: http://www.quickstockquote.com/StockQuoteServic e/#getQuote Property: getQuoteResponse type: http://www.quickstockquote.com/StockQuo teService/#getQuoteResponse Type: http://www.quickstockquote.com/StockQuoteService/#getQuote Property: symbol type: commonj.sdo#String Type: http://www.quickstockquote.com/StockQuoteService/#getQuoteResponse Property: quote type: commonj.sdo#Float and the sample works. If I use a concrete type for the input param instead, for example, xsd:complexType name=GetAccountReportType xsd:sequence xsd:element name=customerID xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType xsd:element name=getAccountReport type=tns:GetAccountReportType/ Then the types that are registered are Type: commonj.sdo#BigDecimal Type: commonj.sdo#BigInteger Type: commonj.sdo#Boolean Type: commonj.sdo#Byte Type: commonj.sdo#Bytes Type: commonj.sdo#ChangeSummary Type: commonj.sdo#Character Type: commonj.sdo#DataObject Type: commonj.sdo#Date Type: commonj.sdo#Double Type: commonj.sdo#Float Type: commonj.sdo#Integer Type: commonj.sdo#Long Type: commonj.sdo#OpenDataObject Type: commonj.sdo#Short Type: commonj.sdo#String Type: commonj.sdo#URI Type: http://www.bigbank.com/AccountService#AccountReport Property: checking type: http://www.bigbank.com/AccountService#CheckingA ccount Property: savings type: http://www.bigbank.com/AccountService#SavingsAcc ount Property: stocks type: http://www.bigbank.com/AccountService#StockAccoun t Type: http://www.bigbank.com/AccountService#CheckingAccount
[C++] SCA usability
I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL - C++ or C++ - WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
[jira] Created: (TUSCANY-502) Regression with test using java.util.Date
Regression with test using java.util.Date - Key: TUSCANY-502 URL: http://issues.apache.org/jira/browse/TUSCANY-502 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-Mx Reporter: Kevin Williams Priority: Blocker Fix For: Java-Mx A previously working DAS test (org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter) now fails with the following error: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:642) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.set(DataObjectUtil.java:1970) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setAndRecyle(DataObjectUtil.java:1976) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate(DataObjectUtil.java:575) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate(DataObjectImpl.java:493) at org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter(ConverterTests.java:90) I have removed this test from the DAS test suite to allow the build to complete until this is resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: Java SDO Date exception?
I pulled the latest from the repository and the DAS test suite fails for me too with the same exception: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' This appears to be an SDO regression and I will open a JIRA. I have also commented out the broken DAS test so that the build will complete. Thanks, --Kevin Simon Laws wrote: Hi Frank I checked out the java project again. The only updates I go were to do with DAS tests AliasTest.java ExceptionTest.java BooksConfigWithAlias.xml No new java code. I still get the exception. Is there one of the provided tests that I should run to try and tie it down a bit? Regards Simon On 6/26/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, We fixed some bugs related to Date types, late last week (Thursday or Friday). If you don't have the very latest SDO code, please try with the latest, and see if it fixes this problem. Otherwise, it looks like there still may be another bug. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/26/2006 05:25:43 AM: I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at
Re: Java SDO Date exception?
OK, thanks Kevin. Have to admit that I haven't got round to trying what Fuhwei Lwo suggested. S On 6/27/06, Kevin Williams [EMAIL PROTECTED] wrote: I pulled the latest from the repository and the DAS test suite fails for me too with the same exception: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' This appears to be an SDO regression and I will open a JIRA. I have also commented out the broken DAS test so that the build will complete. Thanks, --Kevin Simon Laws wrote: Hi Frank I checked out the java project again. The only updates I go were to do with DAS tests AliasTest.java ExceptionTest.java BooksConfigWithAlias.xml No new java code. I still get the exception. Is there one of the provided tests that I should run to try and tie it down a bit? Regards Simon On 6/26/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, We fixed some bugs related to Date types, late last week (Thursday or Friday). If you don't have the very latest SDO code, please try with the latest, and see if it fixes this problem. Otherwise, it looks like there still may be another bug. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/26/2006 05:25:43 AM: I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
Re: [jira] Created: (TUSCANY-502) Regression with test using java.util.Date
Kevin, Can you assign this JIRA to me? I can take a look. Thanks. Fuhwei Lwo Kevin Williams (JIRA) tuscany-dev@ws.apache.org wrote: Regression with test using java.util.Date - Key: TUSCANY-502 URL: http://issues.apache.org/jira/browse/TUSCANY-502 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-Mx Reporter: Kevin Williams Priority: Blocker Fix For: Java-Mx A previously working DAS test (org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter) now fails with the following error: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:642) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.set(DataObjectUtil.java:1970) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setAndRecyle(DataObjectUtil.java:1976) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate(DataObjectUtil.java:575) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate(DataObjectImpl.java:493) at org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter(ConverterTests.java:90) I have removed this test from the DAS test suite to allow the build to complete until this is resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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] Resolved: (TUSCANY-502) Regression with test using java.util.Date
[ http://issues.apache.org/jira/browse/TUSCANY-502?page=all ] Frank Budinsky resolved TUSCANY-502: Resolution: Fixed Fixed in revision 417496. Regression with test using java.util.Date - Key: TUSCANY-502 URL: http://issues.apache.org/jira/browse/TUSCANY-502 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-Mx Reporter: Kevin Williams Priority: Blocker Fix For: Java-Mx A previously working DAS test (org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter) now fails with the following error: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:642) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.set(DataObjectUtil.java:1970) at org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.setAndRecyle(DataObjectUtil.java:1976) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate(DataObjectUtil.java:575) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate(DataObjectImpl.java:493) at org.apache.tuscany.das.rdb.test.ConverterTests.testArbitraryConverter(ConverterTests.java:90) I have removed this test from the DAS test suite to allow the build to complete until this is resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: [C++] SCA usability
On 27/06/06, Simon Laws [EMAIL PROTECTED] wrote: I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL - C++ or C++ - WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Pretty much spot on there. Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Clearly we could do with some code gen capability and we should start thinking about what this should involve. Until then, and for the first Milestone release, we will have to make do with documentation. Perhaps you would like to make a start on this as you have a good grasp of the problem? ;-) Cheers, -- Pete
Re: Java SDO Date exception?
Simon, I just commited the fix for TUSCANY-502 and (likely) your problem. Please let me know if your test is still not working with the latest. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/27/2006 11:46:33 AM: OK, thanks Kevin. Have to admit that I haven't got round to trying what Fuhwei Lwo suggested. S On 6/27/06, Kevin Williams [EMAIL PROTECTED] wrote: I pulled the latest from the repository and the DAS test suite fails for me too with the same exception: java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml.type.internal.XMLCalendar' must be of type 'class java.util.Date' This appears to be an SDO regression and I will open a JIRA. I have also commented out the broken DAS test so that the build will complete. Thanks, --Kevin Simon Laws wrote: Hi Frank I checked out the java project again. The only updates I go were to do with DAS tests AliasTest.java ExceptionTest.java BooksConfigWithAlias.xml No new java code. I still get the exception. Is there one of the provided tests that I should run to try and tie it down a bit? Regards Simon On 6/26/06, Frank Budinsky [EMAIL PROTECTED] wrote: Hi Simon, We fixed some bugs related to Date types, late last week (Thursday or Friday). If you don't have the very latest SDO code, please try with the latest, and see if it fixes this problem. Otherwise, it looks like there still may be another bug. Thanks, Frank. Simon Laws [EMAIL PROTECTED] wrote on 06/26/2006 05:25:43 AM: I need a little help interpreting an exception I'm getting from an SDO test I have. I'm porting some interop tests to HEAD so that I can create a patch and (having updated to use the new DAS) the relational SDO no longer works with date fields . All other types I'm testing are OK. The test basically creates a new data object by copying all the properties from an existing data object one by one. The offending line is newRow.setDate(ADATE, row.getDate(ADATE) ); The exception that is thrown is below. When I comment this line out everything works fine. I'm not sure where to start looking as there is lots of emf stuff here that I'm not familiar with. I took a look at the JIRAs for SDO and it doesn't appear that this is happening for anyone else so there may be something wrong with my setup. If this exception means anything to anyone who knows emf let me know. java.lang.ClassCastException: The value of type 'class org.eclipse.emf.ecore.xml .type.internal.XMLCalendar' must be of type 'class java.util.Date' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleDataStatic.validate(EStructuralFeatureImpl.java:2046) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDele gateSingleData.dynamicSet(EStructuralFeatureImpl.java:1942) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet (BasicEObjectI mpl.java:686) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet (Dynamic DataObjectImpl.java:147) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet( DataObjectImpl.java:1 439) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.jav a:642) at org.apache.tuscany.sdo.impl.DataObjectImpl.set( DataObjectImpl.java:14 0) at org.apache.tuscany.sdo.util.DataObjectUtil.setDate( DataObjectUtil.jav a:570) at org.apache.tuscany.sdo.impl.DataObjectImpl.setDate( DataObjectImpl.jav a:493) at org.apache.tuscany.test.interop.sdo.rdb.InteropTestReadWriteRDB.test5 ReadAndWriteRDB(InteropTestReadWriteRDB.java:178) at org.apache.tuscany.sdo.test.xml.InteropTestCase.testReadWriteRDB (Inte ropTestCase.java:54) 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 junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203)
Re: [C++] SCA usability
Having been working on the Windows build today, I agree with your summary. There might even be problems to less new users. My saviours this afternoon hav been: 1) Running the axis http server in the debugger - loading the extra sca_ws dll and setting breakpoints. 2) Checking very very carefully the env vars TUSCANY_SCACPP, TUSCANY_SDOCPP, TUSCANY_SCACPP_SYSTEM_ROOT. 3) Checking them again. 4) checking the logs in the axis logs directory - Calculator_blocking gives you what happens when the service is loaded. axis2.log tells you if the service didnt load. - I just asked the asix2c people to add some details to the log to say which dll in which path didnt load - then I think we have all bases covered. On 27/06/06, Simon Laws [EMAIL PROTECTED] wrote: I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL - C++ or C++ - WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
Tuscany and Axis2
Hi, How can I build and run Tuscany with Axis2 only for webservices? Thanks, Permaine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ M1 test distro
Was wondering if the download package names should have something that distinguishes between cpp and java? tuscany-cpp-sca-0.1.incubating-M1.tar.gz http://people.apache.org/%7Erobbinspg/tuscany_sca-0.1.incubating-M1.tar.gz ? We didn't do it for java but it is nice when you download both to keep them straight. Edward Slattery wrote: The changes made to the distro on Saturday have made the windows distro no longer work. I think its just a question of the calculator sample - I was working with a 'deploy' directory, where now I think it works in the calculator root, so when I run it I can see both the sca.module in my project and the sca.module in the deploy directory, and I get duplicates. I suggest we use some of Monday to sort this out - Im sure the linux one will be the one most people want anyway. cheers, Ed. On 24/06/06, Pete Robbins [EMAIL PROTECTED] wrote: On 24/06/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I used this binary distro but my machine is Fedora Core3. I got the following problem building the Calculator sample: g++ -g -O2 -o calculator_client Calc.o -L/home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1/lib -ltuscany_sca -L/home/jeremy/Desktop/tuscany_sdo-bin-0.1.incubating-M1/lib -ltuscany_sdo -ltuscany_sdo_axiom -L/home/jeremy/Desktop/axis2c-bin-0.92-linux/lib -laxis2_util -laxis2_axiom -laxis2_wsdl -laxis2_engine -laxis2_parser -laxis2_minizip -lpthread -laxis2_http_sender -laxis2_http_receiver /usr/bin/ld: warning: libtuscany_sca_ws_reference.so.0, needed by /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libstdc++.so.5, needed by /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so, may conflict with libstdc++.so.6 /home/jeremy/Desktop/tuscany_sca-bin-0.1.incubating-M1 /lib/libtuscany_sca.so: undefined reference to `tuscany::sca::ws::WSServiceWrapper::WSServiceWrapper(tuscany::sca::model::WireTarget*)' I assume the conflict on libstc++ is due to distro issues. If I added -ltuscany_sca_ws_reference to the automake files then it built and I was able to run the basic sample :-) Maybe someone can enlighten me wrt linking on linux with automake. If I create a lib A which references libs x,y and z, and z references P, Q and R... when I come to build an executable MyEXE I need to have -lA -lx -ly -lz -lP -lQ -lR. Is this correct? It seems odd that I need to know all the dependencies of the things I depend on. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-477) SDO runtime should report unresolved types in a meaningful way if xsd:import/include cannot be resolved
[ http://issues.apache.org/jira/browse/TUSCANY-477?page=comments#action_12418100 ] Frank Budinsky commented on TUSCANY-477: Yang, the adjusted code you show isn't really the proper way to do it. The problem with the original code is that the XSDHelper being used to define the types (i.e., the one returned from SDOUtil.createXSDHelper) is not the same one that is being used to find the property (i.e., XSDHelper.INSTANCE). The proper way to do it is like this: XSDHelper xsdHelper = SDOUtil.createXSDHelper(SDOUtil.createTypeHelper()); xsdHelper.define(url.openStream(), null); Property property = xsdHelper.getGlobalProperty(http://a;, a, true); SDO runtime should report unresolved types in a meaningful way if xsd:import/include cannot be resolved --- Key: TUSCANY-477 URL: http://issues.apache.org/jira/browse/TUSCANY-477 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1 Reporter: Raymond Feng Assignee: Frank Budinsky Attachments: TestXSDImport.jar I'm seeing different behaviors from XSDHelper.define() if the xsd:import/include cannot be resolved. I wonder if we should have a consistent error handling here. Please see the attached test case (in the case, I pass null as schemaLocation to the define() on purpose). Case 1: Unresolved XSD type is silently replaced by Object DataType Case 2: IllegalArgumentException is thrown due to a NPE in EMF code -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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: Tuscany and Axis2
Permaine Cheung wrote: Hi, How can I build and run Tuscany with Axis2 only for webservices? Thanks, Permaine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Our binary distribution includes a Tomcat server pre-configured to run with our Axis2 based Web Service runtime. In a J2SE environment, to run with the Axis2 based Web Service runtime, simply put the JARs in the lib/axis2 on your classpath instead of the JARs in the lib/celtix directory. If you're building Tuscany from the sources, to build with Axis2 only comment out the binding.celtix module in java/sca/bindings/pom.xml and the celtix samples in samples/sca/pom.xml. To build the distribution with Axis2 only comment out the celtix-overlay module in java/distribution/pom.xml and the reference to the lib/celtix directory in java/distribution/tuscany-polish/fixupJars.xml. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLHelper(SDOUtil for the time being).getSubstitutionValues review
The eMail thread of Question about XSD substitution support in SDO2 ( http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg04167.html) has the context. The proposed feature adding under reviewing is for SDO2 to support XSD substitution better. -- Yang ZHONG
Re: DAS Needs a new parameter marker (T-406)
I believe it is best for the DAS to not manipulate the provided SQL and
also to require that clients provide SQL that conforms to the standard.
I would like to remove support for named parameters if there is no
objection.
Thanks,
--Kevin
Kevin Williams wrote:
The problem is that our marker ':' can be used in SQL although, as far
as I can tell, only within embedded single or double quotes like this:
Select fif:fi'ef from 'sefti:iend' where sdsd:ske =:id and age
:age and addr = :addr
Which we need to convert to
Select fif:fi'ef from 'sefti:iend' where sdsd:ske =? and age ?
and addr = ?
The following algorithm was suggested by Don Clare and seems to work:
final static String Q_MARK = ?;
final static String SQL_QUOTED_SEQUENCE_PATTERN = (['\\\]).*?\\1;
final static String SQL_HOST_VARIABLE_PATTERN = (\\W):(\\w*);
public static String replaceHostVariables(String inStr) {
ArrayListInteger indices = new ArrayListInteger();
indices.add(0);
StringBuffer sb = new StringBuffer();
Pattern p =
Pattern.compile(SQL_QUOTED_SEQUENCE_PATTERN,Pattern.DOTALL);
Matcher m = p.matcher(inStr);
while (m.find()) {
indices.add(m.start());
indices.add(m.end());
}
indices.add(inStr.length());
IteratorInteger i = indices.iterator();
p = Pattern.compile(SQL_HOST_VARIABLE_PATTERN,Pattern.DOTALL);
while (i.hasNext()) {
m.usePattern(p);
m.region(i.next(), i.next());
while (m.find()) {
m.appendReplacement(sb, m.group(1) + Q_MARK);
}
}
m.appendTail(sb);
return sb.toString();
}
EJB supports named parameters as part of EJBQL but only positional
parameters for native queries.
I am really torn here. I see the value in named parms but wonder if
the DAS should have to work so hard to provide it when this is not yet
part of the SQL standard.
Thanks,
--Kevin
Jeremy Boynes wrote:
There are a lot of benefits to named parameters and users seem to like
them - it would be a shame to see them go.
How complex would a parser be? Wouldn't it just need to handle the
distinction between string values/comments etc. and SQL text? That
would be a lot simpler than parsing the actual SQL.
What does EJB3 do for native queries? Can we do something like that
(or better)?
--
Jeremy
On 6/13/06, Kevin Williams [EMAIL PROTECTED] wrote:
DAS has a problem with its attempt to support named parameters in
SQL as in:
command = Factory.createCommand (select * from Customer where
Customer.id = :id)
command.setParm(id, 500);
We have been using a colon as the parameter marker and this works well
since we can do a simple scan of the select statement to find the named
parameter markers and replace them with '?'. Unfortunately, a scan is
not sufficient when the SQL uses colons as part of the statement
itself,
like in an embedded timestamp. To pluck out the parameter markers in
these more complicated cases requires a parser and, IMO, the DAS has no
business parsing SQL.
So, what I propose is to remove support for named parameters altogether
and leave clients with indexed parameter access like this:
command = Factory.createCommand (select * from Customer where
Customer.id = ?)
command.setParm(1, 500);
Any opinions?
Thanks,
--Kevin
-
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]
[C++] M1 test distro - sample compile issue
I down loaded the binary distro unpacked it downloaded Axis2C too and
unpacked but didn't do anything else with it.
Went in to samples and ran ./configure which looked ok.
Then ran make and below is my output which doesn't look right.
Running Fedora Core 4
make all-recursive
make[1]: Entering directory
`/home/rineholt/instpkg/tuscany-cpp/tuscany_sca-bin-0.1.incubating-M1/tuscany_sca-bin-0.1.incubating-M1/samples'
Making all in Calculator
make[2]: Entering directory
`/home/rineholt/instpkg/tuscany-cpp/tuscany_sca-bin-0.1.incubating-M1/tuscany_sca-bin-0.1.incubating-M1/samples/Calculator'
Making all in CalculatorModule
make[3]: Entering directory
`/home/rineholt/instpkg/tuscany-cpp/tuscany_sca-bin-0.1.incubating-M1/tuscany_sca-bin-0.1.incubating-M1/samples/Calculator/CalculatorModule'
make all-am
make[4]: Entering directory
`/home/rineholt/instpkg/tuscany-cpp/tuscany_sca-bin-0.1.incubating-M1/tuscany_sca-bin-0.1.incubating-M1/samples/Calculator/CalculatorModule'
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I. -I../.. -I/include -I/include-g -O2 -MT
CalculatorImpl_CalculatorService_Proxy.lo -MD -MP -MF
.deps/CalculatorImpl_CalculatorService_Proxy.Tpo -c -o
CalculatorImpl_CalculatorService_Proxy.lo
CalculatorImpl_CalculatorService_Proxy.cpp; \
then mv -f .deps/CalculatorImpl_CalculatorService_Proxy.Tpo
.deps/CalculatorImpl_CalculatorService_Proxy.Plo; else rm -f
.deps/CalculatorImpl_CalculatorService_Proxy.Tpo; exit 1; fi
g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I/include -I/include -g -O2 -MT
CalculatorImpl_CalculatorService_Proxy.lo -MD -MP -MF
.deps/CalculatorImpl_CalculatorService_Proxy.Tpo -c
CalculatorImpl_CalculatorService_Proxy.cpp -fPIC -DPIC -o
.libs/CalculatorImpl_CalculatorService_Proxy.o
In file included from CalculatorImpl_CalculatorService_Proxy.cpp:17:
CalculatorImpl_CalculatorService_Proxy.h:21:45: error:
tuscany/sca/core/ServiceWrapper.h: No such file or directory
CalculatorImpl_CalculatorService_Proxy.cpp:19:26: error: osoa/sca/sca.h:
No such file or directory
CalculatorImpl_CalculatorService_Proxy.h:26: error: 'tuscany' has not
been declared
CalculatorImpl_CalculatorService_Proxy.h:26: error: expected `)' before
'*' token
CalculatorImpl_CalculatorService_Proxy.h:33: error: 'tuscany' has not
been declared
CalculatorImpl_CalculatorService_Proxy.h:33: error: ISO C++ forbids
declaration of 'ServiceWrapper' with no type
CalculatorImpl_CalculatorService_Proxy.h:33: error: expected ';' before
'*' token
CalculatorImpl_CalculatorService_Proxy.cpp:20: error: 'osoa' has not
been declared
CalculatorImpl_CalculatorService_Proxy.cpp:20: error: expected
namespace-name before ';' token
CalculatorImpl_CalculatorService_Proxy.cpp:20: error: 'type error' is
not a namespace
CalculatorImpl_CalculatorService_Proxy.cpp:21: error: 'tuscany' has not
been declared
CalculatorImpl_CalculatorService_Proxy.cpp:21: error: expected
namespace-name before ';' token
CalculatorImpl_CalculatorService_Proxy.cpp:21: error: 'type error' is
not a namespace
CalculatorImpl_CalculatorService_Proxy.cpp:29: error: 'ServiceWrapper'
was not declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:29: error: 'target' was not
declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:30: error: expected ',' or
';' before '{' token
CalculatorImpl_CalculatorService_Proxy.cpp:43: error: expected `)'
before '*' token
CalculatorImpl_CalculatorService_Proxy.cpp: In destructor 'virtual
CalculatorImpl_CalculatorService_Proxy::~CalculatorImpl_CalculatorService_Proxy()':
CalculatorImpl_CalculatorService_Proxy.cpp:49: error: 'target' was not
declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:50: error: type 'type
error' argument given to 'delete', expected pointer
CalculatorImpl_CalculatorService_Proxy.cpp: In member function 'virtual
float CalculatorImpl_CalculatorService_Proxy::add(float, float)':
CalculatorImpl_CalculatorService_Proxy.cpp:55: error: 'Operation' was
not declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:55: error: expected `;'
before 'operation'
CalculatorImpl_CalculatorService_Proxy.cpp:56: error: 'operation' was
not declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:60: error: 'target' was not
declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp: In member function 'virtual
float CalculatorImpl_CalculatorService_Proxy::sub(float, float)':
CalculatorImpl_CalculatorService_Proxy.cpp:66: error: 'Operation' was
not declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:66: error: expected `;'
before 'operation'
CalculatorImpl_CalculatorService_Proxy.cpp:67: error: 'operation' was
not declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp:71: error: 'target' was not
declared in this scope
CalculatorImpl_CalculatorService_Proxy.cpp: In member function 'virtual
float CalculatorImpl_CalculatorService_Proxy::mul(float, float)':
[jira] Created: (TUSCANY-503) XSD substitution support in SDO2
XSD substitution support in SDO2 Key: TUSCANY-503 URL: http://issues.apache.org/jira/browse/TUSCANY-503 Project: Tuscany Type: New Feature Components: Java SDO Implementation Environment: Java Reporter: Yang ZHONG Priority: Minor Copied from eMail thread Question about XSD substitution support in SDO2 (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03963.html): Raymond Feng Tue, 13 Jun 2006 16:43:09 -0700 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-503) XSD substitution support in SDO2
[ http://issues.apache.org/jira/browse/TUSCANY-503?page=comments#action_12418135 ] Yang ZHONG commented on TUSCANY-503: Raymond Feng Tue, 13 Jun 2006 16:43:09 -0700 Hi, Taking the SCA 0.9 XSDs as an example, the implementation.java can substitute implementation. element name=implementation type=sca:Implementation/ complexType name=Implementation/ element name=implementation.java type=sca:JavaImplementation substitutionGroup=sca:implementation/ complexType name=JavaImplementation complexContent extension base=sca:Implementation sequence any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ /sequence attribute name=class type=NCName use=required/ anyAttribute namespace=##any processContents=lax/ /extension /complexContent /complexType The XML document is as follows: 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/ /component /module I use XSDHelper.define() to convert the XSD into SDO types, load the XML document using XMLHelper and get a DataObject representing the module. Now the question for the SDO Type of ComponentType, I'm seeing two properties in the debugger, implementation and implementation.java. I want to differentiate these two properties so that I can produce the same XML document when I navigate the DataObject to construct the XMLStreamReader. Do we have a SDO-way here (I know in EMF we can look into the metadata)? Raymond Feng Tue, 13 Jun 2006 17:33:41 -0700 I did some investigation on the EMF implementation and it seems that I need to test if the property is transient (in EMF term). Do we have the same capability in SDO? Jeremy Boynes Wed, 14 Jun 2006 06:24:03 -0700 Shouldn't there just be one property implementation.java whose type is a sub-type of implementation? Raymond Feng Wed, 14 Jun 2006 09:31:30 -0700 By the SDO spec, the component Type (which owns the implementation substitution group) is open and there will be two properties: implementation: normal property in Type.getProperties() list implementation.java: dynamic property in DataObject.getInstanceProperties() list If the type was just open then yes. I thought the intent here though was substitution so wouldn't that mean that the implementation property should contain an implementation.java sub-type instance? Raymond Feng Wed, 14 Jun 2006 10:36:55 -0700 It seems that SDO models XSD substitution group as open content. So in this case, we have two properties: implementation and implementation.java. The DataObject.getXXX(Property) method works for both and returns the same value. And because of this, the code doesn't know if the implementation.java substitutes implementation. As a result, the vaule is incorrectly written twice into the XML stream. Pete Robbins Wed, 14 Jun 2006 12:35:29 -0700 In the C++ implementation you would only get a single property implementation. It's type would be sca:JavaImplementation which is a sub type of Implemetation. I think this is correct as the schema tells us that when loading the instance document to treat implementation.java as implementation so you should not see a property named implementation.java. possibly... Frank Budinsky Wed, 14 Jun 2006 15:03:23 -0700 Raymond is trying to write a serializer, and I presume he wants to produce this: implementation.java ... If the only property on the object is implementation with a value that is an sca:Implementation subclass, you'd get/expect this when serializing: implementation xsi:type=sca:JavaImplementation ... which is valid, but isn't using the substitution group. So it's really the implementation.java property that we need to serialize, but the implementation property is a static property of the Type, so it will always be there. In the Java implementation they both return the same thing, but the serializer needs to know that one is just derived from the other and not to serialize them both. More generally, I'm wondering how the C++ implementation will serialize this. Does it roundtrip back to the same XML that was loaded? Jeremy Boynes Wed, 14 Jun 2006 09:43:43 -0700 XSD substitution support in SDO2 Key: TUSCANY-503 URL: http://issues.apache.org/jira/browse/TUSCANY-503 Project: Tuscany Type: New Feature Components: Java SDO Implementation Environment: Java Reporter: Yang ZHONG Priority: Minor Copied from eMail thread Question about XSD substitution support in SDO2 (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03963.html): Raymond Feng Tue, 13 Jun 2006 16:43:09 -0700 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
Re: XMLHelper(SDOUtil for the time being).getSubstitutionValues review
JIRA issue TUSCANY-503 has been created to track the XSD substitution support in SDO2: http://issues.apache.org/jira/browse/TUSCANY-503 -- Yang ZHONG
[jira] Commented: (TUSCANY-503) XSD substitution support in SDO2
[ http://issues.apache.org/jira/browse/TUSCANY-503?page=comments#action_12418137 ] Yang ZHONG commented on TUSCANY-503: Frank and I propose adding this new method into XMLHelper API to support XSD substitution in SDO2: /** * Gets the Sequence corresponding to the specified substitutable Property of the specified DataObject. * @param dataObject Not null, otherwise NullPointerException. * @param head A substitution group head property. * @return The Sequence corresponding to the specified substitutable Property of the specified DataObject, * null if the specified Property isn't a substitution head. */ Sequence getSubstitutionValues(DataObject dataObject, Property head); Before it reaches the spec, we'll host it in SDOUtil for the time being. XSD substitution support in SDO2 Key: TUSCANY-503 URL: http://issues.apache.org/jira/browse/TUSCANY-503 Project: Tuscany Type: New Feature Components: Java SDO Implementation Environment: Java Reporter: Yang ZHONG Priority: Minor Copied from eMail thread Question about XSD substitution support in SDO2 (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg03963.html): Raymond Feng Tue, 13 Jun 2006 16:43:09 -0700 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-433) User provided CUD with partial update results in NPE
[ http://issues.apache.org/jira/browse/TUSCANY-433?page=all ] Kevin Williams reassigned TUSCANY-433: -- Assign To: Kevin Williams Waiting for patch from Darius User provided CUD with partial update results in NPE Key: TUSCANY-433 URL: http://issues.apache.org/jira/browse/TUSCANY-433 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Assignee: Kevin Williams ApplyChanges with partil userprovided update statement fails with NPE. Test case DefectTests.readModifyAply and readModifyApply1() demonstrate this bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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-504) Ability to find out if a property is required or not
Ability to find out if a property is required or not Key: TUSCANY-504 URL: http://issues.apache.org/jira/browse/TUSCANY-504 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1 Reporter: Suraksha Vidyarthi Ability to get required fields from an SDO definition. Currently there is no mechanism to find out from the SDO instance if a given property is mandatory/required or not. The implementation should be able to use the minOccurs and maxOccurs values from XSD to detect if a field is required or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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]
Question on java generics
Generics gurus,
Assuming I have the following class:
public class TestT {
...
}
1) Is there a way to get the Class object for T in class Test? I know T.class
is illegal.
2) Can I create the an instance of Test using a Class object myClass. I know
new TestmyClass is not valid.
Thanks,
Raymond
Re: Question on java generics
1) No. T is erasable.
2) If myClass is a class or generic type, you should be able to new
TestmyClass.
On the other hand, if myClass is a pointer/variable, no you can't new
TestmyClass
On 6/27/06, Raymond Feng [EMAIL PROTECTED] wrote:
Generics gurus,
Assuming I have the following class:
public class TestT {
...
}
1) Is there a way to get the Class object for T in class Test? I know
T.class is illegal.
2) Can I create the an instance of Test using a Class object myClass. I
know new TestmyClass is not valid.
Thanks,
Raymond
--
Yang ZHONG
Re: Any recursive composition sample?
Thanks for volunteering! The Spring container that Ken is working on will demonstrate how composites function. However, just to be accurate, we do not have *any* samples in core2 yet - it's not just a question about recursion. If people want to develop them and help out that would be greatly appreciated. The reason we don't have them is because when I develop code I prefer writing test cases and using those instead. It's great if people want to volunteer their effort to create samples though. Jim On Jun 21, 2006, at 1:57 AM, Jean-Sebastien Delfino wrote: The last few weeks we've been talking about composites and recursive composition so much... and today I looked for a sample showing the new recursive composition model in our whole code base, including the head and our various sandboxes... and couldn't find any. I think it'll help all of us get our heads around this new model if we can see a few samples. Could somebody point me to a recursive composition sample if we have any and I missed it? Is anybody curious and interested in trying to port a few of our existing samples to the new recursive model? I guess the update of the SCA spec describing the recursive composition is not public yet, but the materials presented at JavaOne are public as far as I know, and should be sufficient to develop samples leveraging the new recursive composition model. If anybody is interested in developing sample scenarios that demonstrate the value of the recursive composition, please let me know, we can work together on this. I'd like to start this activity in parallel with the SPI analysis work that I'm currently doing. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany SPI interfaces
Why do you need to implement an interface as opposed to extend an
abstract class when most of the methods are simple getters/setter
pairs? This is a very common pattern in found in Servlets, Struts,
WebWork, Srping and Hibernate, to name just a few. It allows people
to progressively buy into an extension API, picking up complexity as
needed.
If one wants maximum control, I still think things are very simple,
and this is exactly why I don't like counting methods without going
through what they are intended to do:
public class FooAllAtomicComponent implements AtomicComponentObject {
public boolean isEagerInit() {
return false;
}
public void init(Object instance) throws TargetException {
}
public void destroy(Object instance) throws TargetException {
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public void addInboundWire(InboundWire wire) {
}
public InboundWire getInboundWire(String serviceName) {
return null;
}
public void addOutboundWire(OutboundWire wire) {
}
public void addOutboundWires(Class? multiplicityClass,
ListOutboundWire wires) {
}
public MapString, ListOutboundWire getOutboundWires() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method operation) {
return null;
}
public String getName() {
return null;
}
public CompositeComponent getParent() {
return null;
}
public Scope getScope() {
return null;
}
public Object getServiceInstance() throws TargetException {
return null;
}
public void prepare() {
}
public void publish(Event object) {
}
public void addListener(RuntimeEventListener listener) {
}
public void addListener(EventFilter filter, RuntimeEventListener
listener) {
}
public void removeListener(RuntimeEventListener listener) {
}
public int getLifecycleState() {
return 0;
}
public void start() throws CoreRuntimeException {
}
public void stop() throws CoreRuntimeException {
}
Going in order:
- init/destroy initialize and destroy an instance
- createInstance(), getServiceInstance(String name)
getServiceInterfaces(), createTargetInvoker() are the same as before
- addInboundWire(InboundWire wire) adds an inbound wire to the
component
- addOutboundWire(OutboundWire wire), addOutboundWires(Class?
multiplicityClass, ListOutboundWire wires) provide the outbound
wires to the component
- getOutboundWires() returns the outbound wire
- getName() returns the component name
- getParent() returns the composite parent
- getScope() returns the component scope
- getServiceInstance() returns a default service instance
- prepare() is a callback to signal that the component has been
configured and should prepare itself to receive invocations
- publish(Event object), addListener(RuntimeEventListener
listener), addListener(EventFilter filter, RuntimeEventListener
listener), removeListener(RuntimeEventListener listener) provide
listener services particularly useful to composites
- getLifecycleState() returns the state of the component, e.g.
initializing, etc.
- start() and stop() are callbacks issued by the runtime
All of these methods deal directly with a component and are very easy
to implement. I don't see the need to Balkanize the API. Which of
these methods do you think can be broken out?
Jim
On Jun 21, 2006, at 2:08 AM, Jean-Sebastien Delfino wrote:
Jim Marino wrote:
I think you missed something. With core2, most people will extend
from the helper abstract classes in the SPI extension package
(this was also the case with the previous core). For example:
I didn't miss this class, as I said that's exactly what I'm trying
to avoid. I want to implement the SPI interfaces without having to
extend base implementation classes.
public class FooAtomicComponent extends
AtomicComponentExtensionObject{
public FooAtomicComponent(String name, CompositeComponent?
parent, ScopeContainer scopeContainer, WireService wireService) {
super(name, parent, scopeContainer, wireService);
}
public Object getServiceInstance() throws TargetException {
return null;
}
public Object createInstance() throws ObjectCreationException {
return null;
}
public Object getServiceInstance(String name) throws
TargetException {
return null;
}
public ListClass? getServiceInterfaces() {
return null;
}
public TargetInvoker createTargetInvoker(String serviceName,
Method
