Visitor pattern is not used in Tuscany's core design
I analysed component model object in tuscany. Here my question is: all the component model object has implemented interface [org.apache.tuscany.sca.assembly.Visitable]. But in fact the [accept] method are never invoked. More of it, there is a [Visitor] interface, but nobody implements it. My point of view is: remove these two interface from Tuscany, thus makes core coding a little more simplified and purified. Design pattern is a language between technicans, don't tell them visitor pattern is there used to solve applicable problems. - Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search.
Re: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417)
True, with the approach, DAS can use Metadata API and treat Derby specially (as Derby Embedded Driver API returns FALSE, set it to TRUE) 1) If provided in Config - it will be used, no Metadata API check 2) If not provided in Config - Metadata API check - In this for Derby ALWAYS SET TO TRUE, and for anything else, set based on API return value. In case of exception set to FALSE. 3) Also for existing test cases - default TRUE will be assumed as they run using Derby and will not fail 4) For PostgreSQL - this approach will work as Metadata API returns FALSE for JDBC 3 compliant driver 5) In case there is any driver used which is not JDBC 3 compliant and the API is absent, then it will again be caught as exception and value set to FALSE. Please see if there are any further places for modification in the above. Regards, Amita On 7/24/07, Ron Gavlin [EMAIL PROTECTED] wrote: Hi Amita, Since DAS has JDK 1.4 as a requirement and the JDBC 3.0 APIs are built into JDK 1.4, isn't it sufficient to interpret a JDBC 2.0 driver throwing a exception from supportsGetGeneratedKeys() as a false. Also, since the DAS is currently a pre-1.0 release, I don't think our solution needs to be driven by backwards-compatibility or whether test cases get broken or not. From my perspective, the default case (the absence of the attribute) should be driven by the JDBC driver's DatabaseMetadata.supportsGetGeneratedKeys() value. The useGetGeneratedKeys attribute could be explicitly set to true for cases like Derby where the driver's partial support for this feature is sufficient for the needs of the DAS. In the case of Oracle, they just started supporting getGeneratedKeys() in Oracle 10g R2. It is not supported in earlier versions of the database or drivers. So, using the DatabaseMetadata-driven approach, the DAS should be able to support all Oracle versions out of the box with no special config attribute. In the future, hopefully Derby will implement full getGeneratedKeys() support and thus would not require special configuration within the DAS. My two cents... - Ron - Original Message From: Amita Vadhavkar [EMAIL PROTECTED] To: [EMAIL PROTECTED]; tuscany-dev@ws.apache.org Sent: Tuesday, July 24, 2007 8:56:36 AM Subject: Re: Flexibility in supporting JDBC's Statement.RETURN_GENERATED_KEYS in RDB DAS (JIRA-1417) Hi, Below are some details about the solution for JIRA-1353. Please review the patch. http://issues.apache.org/jira/browse/DERBY-242 - indicates that for 10.1.1.0, DatabaseMetadata.supportsGetGeneratedKeys() returns false. Also, checked that for the current Maven Repo's Derby version (10.1.2.1) same is happening. DatabaseMetadata.supportsGetGeneratedKeys() is not available in JDBC 2.0. (We can catch exception if it is thrown in the supports...() , but we can not detect cases like above - Derby) So, using DatabaseMetadata.supportsGetGeneratedKeys() (when config attribute is not set) may not be reliable in all cases. To keep the fix simple and also not to break existing test cases (which assume default TRUE), the following is changed in patch 1) New Config attribute xsd:attribute name=useGetGeneratedKeys type=xsd:boolean default=true/ 2) Default to TRUE - so old test cases and old configs continue to work 3) Remove vendor name hardcoding logic to set flag useGetGeneratedKeys So, in effect, with this patch (JIRA-1353) user will get an option to pass FALSE, when it is sure that the dbms driver in use does not support this feature. Thus, instead of hardcoding vendor names (without driver versions), the responsibility is given to user to pass FALSE when needed. Have tested this fix on Derby, DB2, MySQL and PostgreSQL. Also, new testcases (6) added - CheckSupportGeneratedKeys example Config XML using the above attribute (say for PostgreSQL), the XML will look as below Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;; useGetGeneratedKeys=false /Config -- User will need to pass the Config during creation of DAS instance. DAS.FACTORY.createDAS(config, getConnection()) or DAS.FACTORY.createDAS(config) or DAS.FACTORY.createDAS(InputStream configStream) The value of the attrib can be true/false. And Driver may/may not support GeneratedKeys. Based on this, following situations can arrive- A Driver supports GeneratedKeys 1]Table is created with one column having GENERATED ALWAYS AS IDENTITY clause, Irrespective of value of useGetGeneratedKeys flag, insert command will succeed true flag value - insert.getGeneratedKey() will return key value false flag value - insert.getGeneratedKey() will throw RuntimeException - Could not obtain generated key! 2]Table is created with no column having GENERATED ALWAYS AS IDENTITY clause, Irrespective of value of useGetGeneratedKeys flag, insert command will
Re: [SCA Native] SDO Build error on Linux
Works fine on all our linuxes including my RHEL... I've removed the unnecessary qualifier so you should be fine now. Cheers, On 25/07/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c -o HelperProvider.lo HelperProvider.cpp; \ then mv -f .deps/HelperProvider.Tpo .deps/HelperProvider.Plo; else rm -f .deps/HelperProvider.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c HelperProvider.cpp -fPIC -DPIC -o .libs/HelperProvider.o ../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88: error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on member 'parseURI' make[6]: *** [HelperProvider.lo] Error 1 make[6]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src/commonj/sdo' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src/commonj' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime/core' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sdo' make: *** [all] Error 2 Any idea? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An idea of WS Service address
You're right, binding.ws does currently require a wsdl be provided, this is something we hope to fix in the next release - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+Next+Release+Contents If the url do provide wsdl and the url of your web service is turning out to be some random endpoint then thats a bug, could you paste in the scdl you are using and the port from your wsdl? ...ant On 7/25/07, shaoguang geng [EMAIL PROTECTED] wrote: Thank you for your attention ant! You encouraged me reading osoa's specification again, then I found your point. OK, now let me speak about my question to some further: I found in WebService_Binding 2.3, wsdl should be generated for an binding.ws, and there follows a generation rule in the spec, OK now we know Tuscany' s binding.ws works noly if we provide a wsdl(not generate it). I don't think it a big problem, but since I found a binding.ws uri=[url] just override the soap:address location=[url], and it seems without this binding.ws's uri, the url of the web service would be some where random(not according to the soap:address's). ant elder [EMAIL PROTECTED] wrote: On 7/18/07, shaoguang geng wrote: When I work on the svn code, I found that the service address of a binding.ws depends on it's uri attribute, not the inside the wsdl file. If the is some thing different from the binding.ws's uri, or it does not exists absolutely, the client will get a confusion form it http://[host]:[port]/[servicename]?wsdl, If I don't give a , I will see a warn, but without the binding.ws' uri, Tuscany runs without any message. The WS service address is calculated based on section 2.1.1 of the WS binding spec and section 1.7.2.1 of the assembly spec (see [1]), and there's a bit about it in the Tuscany doc at [2]. From that, Tuscany should be using the from the WSDL if you reference the WSDL port from the binding.ws wsdlElement= ..., the uri attribute is only used if you don't reference the wsdl port or if it is a relative url. Not sure if that answers you question though? ...ant [1] http://osoa.org/display/Main/Service+Component+Architecture+Specifications [2] http://incubator.apache.org/tuscany/sca-java-bindingws.html - Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us.
Re: Resolving WSDL/XSD import/include for SCA contributions
Hi, Raymond: I also noticed the same problem when testing Tuscany two days ago. I'm not familiar with WSDL4j. When I looked into the codes, my fist response is replacing WSDLLocator, as you mentioned. While the ugly thing is that WSDLLocator return InputSource instead of some sort of placeholder/delegate. We rough thought is use some sort of lazy-import/include way to get around this problem(If you can't stop the aggressive resolveing, you cheat it). So you might want a dummy WSDLDefinition for return instead of implementing a dummy InputSource. You just record the location of the wsdl file in the read() phase, and resolve all the recorded wsdl files in the resolve() phase, then replace the dummies with the real ones. This can promise you to have the right InputSource. The last thing I want to do is implements your own WSDLFactory and WSDLReader by subclassing the default. What's more, SDO has its XSDHelper to parse all the xsd files to load all SDO types they need ( That is to say, some SDO implementation may registered their own XSDDocumentProcessor). So the Tuscany may need some kind of mechanism to allow delegating the resolving of namespace in wsdl to SDO's TypeHelper.(That is why I prefer the use of namespace to schemaLocation) Another problem we saw in WSDL in Tuscany is WSDLOperation. Where multiple output parts is not supported explicitly. Then what if some service return an array of objects as return? - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 25, 2007 10:29 AM Subject: Re: Resolving WSDL/XSD import/include for SCA contributions Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 24, 2007 6:46 PM Subject: Re: Resolving WSDL/XSD import/include for SCA contributions Two questions inline. Raymond Feng wrote: Hi, I'm working on the artifact processing of WSDL/XSD from SCA contributions, especially for the import/include directives. I would like to share what I have so far to get your feedback. Let's assume we have the following artifacts ([1][2]). * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl * helloworld-interface.wsdl (inline schema) imports greeting.xsd * greeting.xsd includes name.xsd For the import/include, we could have different ways to use the location attribute for a WSDL import. Please note the SCA spec says the explicit location attribute should be honored. If it's not present, then we use the namespace-based resolution defined by SCA. 1. location=helloworld-interface.wsdl (relative to the base document where the import is defined) 2. location=/wsdl/helloworld-interface.wsdl (relative to a SCA contribution) 3. location=http://example.com/helloworld-interface.wsdl; (absolute URL pointing to an external resource) 4. location= or location is not present: Use the namespace to resolve the imported definition Is location= even valid? I didn't think so. I have clarified this on the follow-up e-mail. The location attribute is required for import.wsdl. doesn't seem to be a valid URI. The absence of schemaLocation for xsd:import and xsd:include are valid though. We have two options here: a) Plugin a tuscany-specific resolver for WSDL4J (javax.wsdl.xml.WSDLLocator) and XmlSchema (org.apache.ws.commons.schema.resolver.URIResolver). This option can handle location case 1, 2 and 3. For 2, we probably need some context from the contribution service. The difficulty is that both resolvers expect to take an InputSource. For location case 4 (empty or not present), we don't have a corresponding InputSource. I was going to respond with a long list of pros-cons for both options, then deleted all my comments to ask a simple question :). Why can't we return an InputSource for the contents of the imported document? Well, for the import/include that can be resolved to a document, we return the InputSource. I have said that it works for location case 1, 2 and 3. But if the import/include only doesn't have the schemaLocation attribute, what InputSource should we return? A related question, for an artifact processer that loads multiple artifacts following the import/include directives, how can we avoid the duplicate loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl are in the same contribution and they are processed by the WSDL artifact processor. We probably don't want to load b.wsdl twice in this case. To make WSDL4J happy, we might be able to provide a dummy InputSource pointing to a byte array which contains the empty definition (AFAIK, null InputSource won't work) and then resolve the imported definition by QName during the resolve() phase. b) Disable the import/include resolving feature and re-link the related
Why SCA10 specify interface.java
In SCA java component implementation 1.0, most of the spec was telling the story about interface.java interface=[interface name]. But in fact implementation.java class=[class name]/ has done every thing. Dose osoa mean: using interface.java the interface MAY NOT BE an interface of the implementation class? - Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
[jira] Commented: (TUSCANY-1143) Generated code should separate metadata creation from registration to permit proper scoping
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515241 ] Kelvin Goodson commented on TUSCANY-1143: - adding the missing instrumental word to Fuhwei's comment above ... ... when the sub-type has the same name as the super-type ... Generated code should separate metadata creation from registration to permit proper scoping --- Key: TUSCANY-1143 URL: https://issues.apache.org/jira/browse/TUSCANY-1143 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Kelvin Goodson Fix For: Java-SDO-1.0 Attachments: 1143.patch, 1143.patch, 1143.patch, 1143.patch The switch to registration of metadata from the global scope to selected scopes is not complete yet, although for all current test cases there are no failures. Currently the generated init() method for a factory calls the deprecated SDOUtil.registerStaticTypes for its simple dependencies. In the simple case this is just ModelFactory and SDOFactory, but could contain other user generated dependencies if for example there were to be an xsd import of another namespace (exposed a gap in our test case set). This would mean that the user generated model dependency would also be registered against the global registry. It is proposed that all registrations, including the built in models, are made against the helper context provided to the Factory's register method. I.e. a state invariant that no models are ever registered against the global registry. The pattern of looking up models from within packages is not required, since the code can just refer to each model's singleton INSTANCE (see below for the exception SDOFactoryImpl). Creation of the metadata should be done in the init method, and the registration of all metadata (built-in or otherwise) should be done in the register method. It would appear on inspection that no reference to the simple dependencies of a factory need be made in its init method, and simple reference to the dependencies INSTANCE in the register will be enough to ensure that those dependencies are initialised before being registered against the provided scope. SDOFactoryImpl does not have an INSTANCE currently. The current proposed solution is to modify SDOFactory to have an INSTANCE, in order that it can behave like an ordinary generated dependency in this new approach. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Non remoteable interface errors
CompositeActivatorImpl::createServiceWire() identifies the target operation as follows Operation targetOperation = interfaceContractMapper.map( targetContract.getInterface(), operation); This can return null in some circumstances, for example, of you try to expose a non remoteable interface as a web service as I did. The resulting null target operation is passed down into the wire construction logic and as you may expect causes problems. We could trap this case here but shouldn't this be caught by the builder somewhere? Can someone point me in at the right bit of code in the composite builder. Simon
Re: Why SCA10 specify interface.java
Hi Shaoguang,
shaoguang geng wrote:
In SCA java component implementation 1.0, most of the spec was telling the story about interface.java
interface=[interface name]. But in fact implementation.java class=[class
name]/ has done every thing.
Dose osoa mean: using interface.java the interface MAY NOT BE an interface of
the implementation class?
SCA follows the principle of Service Oriented Architecture in separating
the interface of a service from its implementation.
So, where you have a service component implemented by a Java class, it
is expected that there will be an interface definition for the service
offered by the component. This service interface must be one of the
interfaces implemented by the Java class.
So, let us say that we have a service which is defined by the Java
interface:
com.foo.ServiceA
And that we have an implementation of the service provided by a class
com.foo.ServiceImpl
The ServiceImpl class is going to look something like this:
package com.foo;
public class ServiceImpl implements ServiceA {
public String someOperation( String bar ) {
...
...
}
}
Note that the class implements the interface com.foo.ServiceA - if there
is only one interface implemented by the class, this will be assumed to
be the service interface provided by the class. If there are multiple
interfaces implemented by the class, the SCA @Service annotation can be
used to indicate which service each interface belongs to.
In a composite file which holds the service component, the declarations
could look something like this:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=CompositeA
component name=ServiceAComponent
implementation.java class=com.foo.ServiceImpl /
service name=ServiceName
interface.java interface=com.foo.ServiceA/
/service
/component
...
/composite
So, this says that the component named ServiceAComponent is implemented
by the class com.foo.ServiceImpl. That component has a service with the
name ServiceName which has an interface described by the Java interface
com.foo.ServiceA.
Strictly speaking, writing out the service.../ element in full like
this is not necessary in the composite file - the information can be
introspected from the Java class - but it is valid to do this.
Note that while the Java interface may be used to define the service in
the Java class, it is possible to use a different interface language
like WSDL in the composite file, as long as the WSDL definition and the
Java definition of the interface match each other.
I hope that this helps explain things.
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1312) Can not expose Java Implementation class as a service
[ https://issues.apache.org/jira/browse/TUSCANY-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515245 ] 耿韶光 commented on TUSCANY-1312: -- I think this error you got, is something correct in Tuscany. In fact to implement an component with java, use implementation.java class=[class name]/ will work find, although the osoa's spec has mentioned interface.java interface=[class name]/. In Tuscany, the second way will work find with a binding.ws followed. I think this is enought and logical. Use interface.java interface=[class name]/ just mess things. Can not expose Java Implementation class as a service - Key: TUSCANY-1312 URL: https://issues.apache.org/jira/browse/TUSCANY-1312 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-Next Environment: Ubuntu7.04+IBM JDK5+Eclipse3.2.2 Reporter: Zhenghui Lee Fix For: Java-SCA-Next In SCA_javaComponentImplementation_v100 spec, It is saying that a service's interface can be defined by a java class(as opposed to a java interface), I gave try on it, run into following exception, seems that current runtime behavior only allow service defined by interface now. org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType: Service must be an interface at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:263) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68) at tuscany.sample.sync.customer.CustomerImplTest.setUp(CustomerImplTest.java:17) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType: Service must be an interface at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:106) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 16 more Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.tuscany.sca.implementation.java.introspect.impl.InvalidServiceType: Service must be an interface at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:121) at org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:387) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:466) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:83) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:73)
Re: An idea for WS Reference
Thank you for your guiding explain. You point out there is something great to me. Do I understand you right? I cound use META-INF/sca-contribution.xml at client side contribution import namespace= location=[url of the wsdl]/ /contribution to load the wsdl, instead of place it in the classpath:/wsdl Mike Edwards [EMAIL PROTECTED] wrote: Shaoguang, The SCA specifications allow for the WSDL file to be referenced from a single location, which can include a remote location, via mechanisms such as wsdl:location or via the SCA artifact resolution mechanism (see SCA Assembly spec at www.osoa.org). So copying the WSDL file is not necessary. However, for a Java developer, there is usually the need to derive a Java interface from the WSDL in order to write the Java code for that interface. It is always possible then, that the Java interface gets out of sync with the WSDL file. There is no easy way around this, but the SCA runtime can at least check for compatibility and raise a fault if they do not match. Yours, Mike. shaoguang geng wrote: WS consumer will have to put a wsdl file in it class root, the SCADomain load it automaticly. But this brings a problem if the provider's wsdl changed. So first I think if the consumer could load the wsdl from http://[host]:[port]/[servicename]?wsdl,. There by, when debug the wsdl, the developer will have to edit on the two side. Would anyone think this a better idea? - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
[jira] Commented: (TUSCANY-1399) Generate SDO test classes using maven-sdo-plugin
[ https://issues.apache.org/jira/browse/TUSCANY-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515246 ] Kelvin Goodson commented on TUSCANY-1399: - To do this we need to add another project to the SDO reactor build that is purely for this purpose. The reason is that we can not exercise the plugin in the tools project because it introduces circular maven dependencies --- sdo-tools - sdo-plugin. So we need to add an sdo-tools-test project or the like that adds sdo-tools and sdo-plugin as dependencies. Generate SDO test classes using maven-sdo-plugin Key: TUSCANY-1399 URL: https://issues.apache.org/jira/browse/TUSCANY-1399 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Reporter: Ron Gavlin Priority: Minor Tuscany needs a better way to test the various options supported by the XSD2JavaGenerator. The first step is to code-generate test classes on the fly using the maven-sdo-plugin rather than managing code-generated classes directly within SVN. Then a significant number of the same tests could be run multiple times using different options passed to the maven-sdo-plugin. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release process guide checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Hi, I'd like the release guide if the steps we follow are a bit different than what is normally done or if there are some variations to how we perform some steps. But if we were just about going to rephrase all of what has already been said somewhere else I'd prefer just about having a pointer from Tuscany. Maybe a good begining to all of this could be to have our release guide and link to the information that is available. Then as we get to review and apply that we could flesh our guide. Having said that, I'd like us to have a 'release review checklist' that enlists the bunch of things that need to be reviewed in a RC including things like testing out the binary distro before the source distro. etc. - Venkat On 7/24/07, Simon Laws [EMAIL PROTECTED] wrote: snip.. There's already lots of doc about doing releases in the ASF - on the ASF main dev pages and within the Incubator site etc. The problem with there being lots of docs is that there are, ahem, lots of docs. Where is the definitive set of guides that provide the detail required to release Tuscany for someone, like me, who hasn't done it before? Possibly an impossible question to answer as you don't know what I don't know and I don't know what you do know so our view of what is an acceptable level of detail probably differs. Here are the top level guides I found. http://www.apache.org/dev/#rreleases http://incubator.apache.org/guides/releasemanagement.html I can't say whether the above links are satisfactory as I haven't been through the process but I agree that we should propose updates if they are found to be wanting. For example, a discussion of RAT. For consistency I would expect to see all the keystrokes recorded that are required to produce and distribute a release. The fewer the better so, yes, more automation would be good. I expect automation does not completely remove the responsibility to check the release against release criteria, e,g, legal, but gives a good indication of what is required to make the release happen. Again anything we can do to automate these checks is good. I don't expect that release is a process that should involve a lot of imagination on our part other than in providing more automation of the required steps. To put it another way is there anything specific we have to do for Tuscany that would not be included in the general guide? I note that many projects do have release guides. Why is this the case? http://httpd.apache.org/dev/release.html http://cayenne.apache.org/release-guide.html http://incubator.apache.org/servicemix/release-guide.html http://activemq.apache.org/release-guide.html I do note that the Incubator release guide states Different options or opinions are encouraged.. If options are offered (and I can't say that there are without reading the detail) then we need a place to document which are chosen for Tuscany releases. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synapse using SCA assembly model for configuration
Maybe we should step back a bit and get more of a common understanding of what the sca support would look like. From that suggestion it sounds like there'd be one synapse.xml file holding all the config (as there is today) and within that would be the xml using the sca namespace to define the SCA services, references and components etc. Eg, something like a synapse.xml file containing: definitions xmlns=http://ws.apache.org/ns/synapse; xmlns:sca=http://www.osoa.org/xmlns/sca/1.0; sca:service name=HelloWorldService sca:interface.wsdl interface= http://helloworld#wsdl.interface(HelloWorld) / sca:binding.ws uri=HelloWorldService/ /sca:service ... /definitions Is that what you mean? I was thinking the SCA definitions would be separate, so there'd be something like an sca-contributions folder within the existing Synapse repository and in there you'd put individual sca composte files or sca contribution jars. Eg something like a helloworld.composite file containing: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=helloworld service name=HelloWorldProxy promote=HelloWorldMediator interface.wsdl interface= http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service component name=HelloWorldMediator implementation.mediator.../ /component reference name=HelloWorldEndpoint promote=HelloWorldMediator binding.ws uri=http://remote/helloservice; / /reference /composite ...ant On 7/25/07, Paul Fremantle [EMAIL PROTECTED] wrote: Well actually I had a different idea. At the moment the Mediator reading is pluggable - based on the namespace, but the core reading of Synapse.XML is fixed. What if we restructured so that we key the XMLConfigurationBuilder off of the XML namespace of the document element in synapse.xml? That way we could make the XML parsing pluggable. We could do it in the same way as we do for Mediators. In other words we could have a JAR file that registers itself as the reader for a given NS. What do you think? Paul On 7/25/07, ant elder [EMAIL PROTECTED] wrote: On 7/24/07, ant elder [EMAIL PROTECTED] wrote: On 7/24/07, Paul Fremantle [EMAIL PROTECTED] wrote: I recently read Dan's blog entry on the SCA assembly model: http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ That and some other discussions I've had made me think about maybe offering the SCA assembly model to configure Synapse. So it seems to me that you can draw a direct correlation between: Synapse Proxy and SCA Service Synapse Endpoint and SCA reference Synapse Mediator - a specific type of SCA Component Synapse Property - SCA Property If we were to make the XMLConfigurationBuilder pluggable then we could just use this as an alternative configuration language. We did talk about this in the beginning of Synapse [we discussed having a LEX/YACC style config language - which I would still LOVE if someone wants to do that - it would make a great Computer Science project] Anyway back to SCA, it seems to me that this would be a pretty nice alternative config model, using an independent third party language. I'm guessing that there is plenty of Tuscany code could help us implement this. Maybe we might do it jointly? So I'm imagining the existing runtime being *exactly* the same as today, but being able to use a subset of the SCA Assembly model to configure it. Maybe some of the SCA wizards on tusc-dev can jump in and let me know if this is feasible? Paul PS If someone is looking at http://www.infoq.com/news/2007/07/scaproblem and wondering where this is coming from I offer a few thoughts. Firstly, I'm always open to being proved wrong! Secondly, this would not be adding any layers of indirection... I'm mapping directly from SCA concepts into the Synapse runtime with this idea. Finally, I see nothing wrong with holding several inconsistent viewpoints at the same time :) Great idea. This is definitely feasible, and also i think it would be really useful - so good for Synapse and good for Tuscany. You're right, we do have plenty of code in Tuscany that we can use, a big part of recent Tuscany releases has been around modularizing the code base to make exactly this type of thing easy to do. So I'd like take you up on the suggestion to do this jointly, as it turns out, i can even spend a bit of time helping make this happen. Let me go pull some things together and I'll post more about it tomorrow. ...ant Had a quick look at how sca support could be plugged into the existing Synapse runtime, not sure how to hook in to the existing initialization code without some code changes to Synapse. One option would be to add a new Axis2 module that is initialized after the existing Synapse module. That could then pick up the SynapseEnvironment and SynapseConfiguration objects from
Re: Release process guide checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
As an example of how much simpler things could be if we got our maven builds set up so maven automated everything see: http://incubator.apache.org/cxf/building.html#Building-Performingarelease But, I still think a RM should understand whats going on so mvn shouldn't be a substitute for having read all the ASF and Incubator doc about releases. ...ant On 7/25/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I'd like the release guide if the steps we follow are a bit different than what is normally done or if there are some variations to how we perform some steps. But if we were just about going to rephrase all of what has already been said somewhere else I'd prefer just about having a pointer from Tuscany. Maybe a good begining to all of this could be to have our release guide and link to the information that is available. Then as we get to review and apply that we could flesh our guide. Having said that, I'd like us to have a 'release review checklist' that enlists the bunch of things that need to be reviewed in a RC including things like testing out the binary distro before the source distro. etc. - Venkat On 7/24/07, Simon Laws [EMAIL PROTECTED] wrote: snip.. There's already lots of doc about doing releases in the ASF - on the ASF main dev pages and within the Incubator site etc. The problem with there being lots of docs is that there are, ahem, lots of docs. Where is the definitive set of guides that provide the detail required to release Tuscany for someone, like me, who hasn't done it before? Possibly an impossible question to answer as you don't know what I don't know and I don't know what you do know so our view of what is an acceptable level of detail probably differs. Here are the top level guides I found. http://www.apache.org/dev/#rreleases http://incubator.apache.org/guides/releasemanagement.html I can't say whether the above links are satisfactory as I haven't been through the process but I agree that we should propose updates if they are found to be wanting. For example, a discussion of RAT. For consistency I would expect to see all the keystrokes recorded that are required to produce and distribute a release. The fewer the better so, yes, more automation would be good. I expect automation does not completely remove the responsibility to check the release against release criteria, e,g, legal, but gives a good indication of what is required to make the release happen. Again anything we can do to automate these checks is good. I don't expect that release is a process that should involve a lot of imagination on our part other than in providing more automation of the required steps. To put it another way is there anything specific we have to do for Tuscany that would not be included in the general guide? I note that many projects do have release guides. Why is this the case? http://httpd.apache.org/dev/release.html http://cayenne.apache.org/release-guide.html http://incubator.apache.org/servicemix/release-guide.html http://activemq.apache.org/release-guide.html I do note that the Incubator release guide states Different options or opinions are encouraged.. If options are offered (and I can't say that there are without reading the detail) then we need a place to document which are chosen for Tuscany releases. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synapse using SCA assembly model for configuration
Not quite. In my suggestion if you wanted sca then the synapse.xml would look like: composite xmlns=...sca namespace /composite But maybe I don't understand the contribution model well enough. Paul On 7/25/07, ant elder [EMAIL PROTECTED] wrote: Maybe we should step back a bit and get more of a common understanding of what the sca support would look like. From that suggestion it sounds like there'd be one synapse.xml file holding all the config (as there is today) and within that would be the xml using the sca namespace to define the SCA services, references and components etc. Eg, something like a synapse.xml file containing: definitions xmlns=http://ws.apache.org/ns/synapse; xmlns:sca= http://www.osoa.org/xmlns/sca/1.0; sca:service name=HelloWorldService sca:interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / sca:binding.ws uri=HelloWorldService/ /sca:service ... /definitions Is that what you mean? I was thinking the SCA definitions would be separate, so there'd be something like an sca-contributions folder within the existing Synapse repository and in there you'd put individual sca composte files or sca contribution jars. Eg something like a helloworld.composite file containing: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=helloworld service name=HelloWorldProxy promote=HelloWorldMediator interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service component name=HelloWorldMediator implementation.mediator.../ /component reference name=HelloWorldEndpoint promote=HelloWorldMediator binding.ws uri=http://remote/helloservice; / /reference /composite ...ant On 7/25/07, Paul Fremantle [EMAIL PROTECTED] wrote: Well actually I had a different idea. At the moment the Mediator reading is pluggable - based on the namespace, but the core reading of Synapse.XML is fixed. What if we restructured so that we key the XMLConfigurationBuilder off of the XML namespace of the document element in synapse.xml? That way we could make the XML parsing pluggable. We could do it in the same way as we do for Mediators. In other words we could have a JAR file that registers itself as the reader for a given NS. What do you think? Paul On 7/25/07, ant elder [EMAIL PROTECTED] wrote: On 7/24/07, ant elder [EMAIL PROTECTED] wrote: On 7/24/07, Paul Fremantle [EMAIL PROTECTED] wrote: I recently read Dan's blog entry on the SCA assembly model: http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ That and some other discussions I've had made me think about maybe offering the SCA assembly model to configure Synapse. So it seems to me that you can draw a direct correlation between: Synapse Proxy and SCA Service Synapse Endpoint and SCA reference Synapse Mediator - a specific type of SCA Component Synapse Property - SCA Property If we were to make the XMLConfigurationBuilder pluggable then we could just use this as an alternative configuration language. We did talk about this in the beginning of Synapse [we discussed having a LEX/YACC style config language - which I would still LOVE if someone wants to do that - it would make a great Computer Science project] Anyway back to SCA, it seems to me that this would be a pretty nice alternative config model, using an independent third party language. I'm guessing that there is plenty of Tuscany code could help us implement this. Maybe we might do it jointly? So I'm imagining the existing runtime being *exactly* the same as today, but being able to use a subset of the SCA Assembly model to configure it. Maybe some of the SCA wizards on tusc-dev can jump in and let me know if this is feasible? Paul PS If someone is looking at http://www.infoq.com/news/2007/07/scaproblem and wondering where this is coming from I offer a few thoughts. Firstly, I'm always open to being proved wrong! Secondly, this would not be adding any layers of indirection... I'm mapping directly from SCA concepts into the Synapse runtime with this idea. Finally, I see nothing wrong with holding several inconsistent viewpoints at the same time :) Great idea. This is definitely feasible, and also i think it would be really useful - so good for Synapse and good for Tuscany. You're right, we do have plenty of code in Tuscany that we can use, a big part of recent Tuscany releases has been around modularizing the code base to make exactly this type of thing easy to do. So I'd like take you up on the suggestion to do this jointly, as it turns out, i can even spend a bit of time helping make this happen. Let me go pull some things together and I'll post more about it tomorrow. ...ant Had a quick look at how sca support
Re: [SCA Native] SDO Build error on Linux
Jean-Sebastien Delfino wrote: Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c -o HelperProvider.lo HelperProvider.cpp; \ then mv -f .deps/HelperProvider.Tpo .deps/HelperProvider.Plo; else rm -f .deps/HelperProvider.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c HelperProvider.cpp -fPIC -DPIC -o .libs/HelperProvider.o ../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88: error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on member 'parseURI' Any idea? It's very likely that this is the same as http://issues.apache.org/jira/browse/TUSCANY-1425, which has been sitting around for a while. Just a reminder, we do need this in the branch as well, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1425) Compile failure on Fedora 6
[ https://issues.apache.org/jira/browse/TUSCANY-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins resolved TUSCANY-1425. --- Resolution: Fixed Fix Version/s: Cpp-Next Compile error fixed in branch and head Warning fixed in TypeImpl.cpp as per patch Compile failure on Fedora 6 --- Key: TUSCANY-1425 URL: https://issues.apache.org/jira/browse/TUSCANY-1425 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-Next Environment: Fedora 6 Reporter: Caroline Maynard Priority: Critical Fix For: Cpp-Next Attachments: tuscany-1425.patch A PHP user reports a compile failure on Fedora 6. The attached change to SDOSchemaSAX2Parser.hsorts it, and seems benign on Win. FWIW, I also attach a fix for a compiler warning in TypeImpl.cpp. The patch is against the pre-2.1 branch, which we're currently using for PHP, but should be applied against the trunk too, please. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] SDO Build error on Linux
The fix is in the branch as well. Sorry I did not see that Jira. On 25/07/07, Caroline Maynard [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Trying to build Native/C++ SDO on Linux RHEL5 gives me this error: if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c -o HelperProvider.lo HelperProvider.cpp; \ then mv -f .deps/HelperProvider.Tpo .deps/HelperProvider.Plo; else rm -f .deps/HelperProvider.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2 -g -O0 -MT HelperProvider.lo -MD -MP -MF .deps/HelperProvider.Tpo -c HelperProvider.cpp -fPIC -DPIC -o .libs/HelperProvider.o ../../../../../runtime/core/src/commonj/sdo/SDOSchemaSAX2Parser.h:88: error: extra qualification 'commonj::sdo::SDOSchemaSAX2Parser::' on member 'parseURI' Any idea? It's very likely that this is the same as http://issues.apache.org/jira/browse/TUSCANY-1425, which has been sitting around for a while. Just a reminder, we do need this in the branch as well, please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1353: - Attachment: 1353.patch patch dated Jul 25 based on http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20715.html Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Assignee: Amita Vadhavkar Priority: Critical Attachments: 1353.patch, 1353.patch Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Raymond, How does this relate to the contribution resolution mechanism described by the SCA specifications? Yours, Mike. Raymond Feng wrote: Hi, We currently use XmlSchema to load XSDs. To resolve the import/include directives using our schemes, we provide an implementation of org.apache.ws.commons.schema.resolver.URIResolver and set it to org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the schemaLocation attribute for the xsd:import or xsd:include is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, xsd:import namespace=http://ns1/. Without the schemaLocation, we resolve the import/include by namespace. In this case, we already have a map keyed by namespace for a list of XmlSchema objects loaded from a catalog or other files and we want to reuse them. Would it be possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that we can override/customize the behavior to associate existing XmlSchema instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to keep the schema map is not always feasible. Another observation is that a NPE will be thrown if the URIResolver.resolveEntity() returns null. Is there any way to disable the aggressive resolving/loading of import/include? [EMAIL PROTECTED] Raymond Feng Apache Tuscany - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1470) Generated SDO APIs have compilation errors when sub-type has the same name as super-type
[
https://issues.apache.org/jira/browse/TUSCANY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1470.
-
Resolution: Fixed
Generated SDO APIs have compilation errors when sub-type has the same name as
super-type
Key: TUSCANY-1470
URL: https://issues.apache.org/jira/browse/TUSCANY-1470
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-1.0
Environment: WinXP
Reporter: Fuhwei Lwo
Fix For: Java-SDO-1.0
Attachments: 1470.patch
Run the codegen tool on src/test/resources/extensible/infostreet.xsd. The
generated code like the one below cannot be compiled because
SDO_PROPERTY_COUNT becomes ambiguous.
*infostreet.xsd*
xsd:complexType name=InfoType
xsd:complexContent
xsd:extension base=customer:InfoType
xsd:sequence
xsd:element name=street
type=xsd:string /
/xsd:sequence
/xsd:extension
/xsd:complexContent
/xsd:complexType
public class InfoTypeImpl extends InfoTypeImpl implements InfoType
{
public final static int STREET = InfoTypeImpl.SDO_PROPERTY_COUNT + 0;
public final static int SDO_PROPERTY_COUNT =
InfoTypeImpl.SDO_PROPERTY_COUNT + 1;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA Native] SDO Build error on Linux
Pete Robbins wrote: Works fine on all our linuxes including my RHEL... I've removed the unnecessary qualifier so you should be fine now. Cheers, Thanks Pete, I just updated from SVN, I'm flying to Portland today as I'm going to the OSCON conference, I'll try again from the airport :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1479) The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535 bytes limit
The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535
bytes limit
-
Key: TUSCANY-1479
URL: https://issues.apache.org/jira/browse/TUSCANY-1479
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-beta1
Environment: Rational 7.0.0.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
j9vmxi3223ifx-20070323 (JIT enabled)
Reporter: Eric Coolman
I am attempting to have a number of root objects creatable from a single
factory, ie. my main xsd contains a number of imports:
xsd:include schemaLocation=SyncItemClass.xsd/
xsd:include schemaLocation=SyncCatalog.xsd/
xsd:include schemaLocation=AddRFQ.xsd/
xsd:include schemaLocation=CancelRFQ.xsd/
xsd:include schemaLocation=ProcessPO.xsd/
... etc.
This works well for me with the SDO Generator in RAD, but tuscany is generating
a very large createXSDMetaData() method that will not compile:
java.lang.Error: Unresolved compilation problem:
The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the
65535 bytes limit
at
com.ibm.ocs.sdo.impl.SdoFactoryImpl.createXSDMetaData(SdoFactoryImpl.java:10695)
at
com.ibm.ocs.sdo.impl.SdoFactoryImpl.initializeMetaData(SdoFactoryImpl.java:10692)
at com.ibm.ocs.sdo.impl.SdoFactoryImpl.init(SdoFactoryImpl.java:3455)
at com.ibm.ocs.sdo.SdoFactory.clinit(SdoFactory.java:28)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:187)
at
com.ibm.ocs.sdo.test.ProcessPOTestCase.testSerializePO(ProcessPOTestCase.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.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
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
The createXSDMetaData method looks like this fragment:
protected void createXSDMetaData(ModelFactoryImpl theModelPackageImpl)
{
super.initXSD();
Property property = null;
addXSDMapping
(acknowledgeCompanyType,
new String[]
{
name, AcknowledgeCompany,
kind, elementOnly
});
addXSDMapping
(getProperty(acknowledgeCompanyType,
AcknowledgeCompanyImpl.INTERNAL_HEADER),
new String[]
{
kind, element,
name, header
});
addXSDMapping
(controlVerbType,
new String[]
{
name, ControlVerb,
baseType, commonj.sdo#String,
enumeration, GET GETLIST SHOW LIST VALIDATE ACKNOWLEDGE ADD CHANGE
CANCEL PROCESS REGISTER RESPOND SYNC
});
addXSDMapping
(countryCodeType,
new String[]
{
name, countryCode,
baseType, commonj.sdo#String,
enumeration, AD AE AF AG AI AL AM AN AO AQ AR AS AT AU AW AX AZ BA BB
BD BE BF BG BH BI BJ BM BN BO BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL
CM CN CO CR CS CU CV CX CY CZ DE DJ DK DM DO DZ EC EE EG EH ER ES ET FI FJ FK
FM FO FR GA GB GD GE GF GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT
HU ID IE IL IN IO IQ IR IS IT JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB
LC LI LK LR LS LT LU LV LY MA MC MD MG MH MK ML MM MN MO MP MQ MR MS MT MU MV
MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN
PR PS PT PW PY QA RE RO RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR ST
SV SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA
VC VE VG VI VN VU WF WS YE YT ZA ZM ZW
});
addXSDMapping
(currencyCodeType,
new String[]
{
name,
FW: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid
Hi, I uploaded a patch for C++ SDO which fixes its XML serialization to produce XML valid against schemas with elementFormDefault=true. If someone could verify and apply it that would be great. This gets the SCA sample CppBigBank working again. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 2:22 PM To: tuscany-dev@ws.apache.org Subject: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid [ https://issues.apache.org/jira/browse/TUSCANY-1478?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1478: --- Attachment: TUSCANY-1478.txt This patch resolves the issue and adds a unit test. For schemas with elementFormDefault=true, serialized instance documents are invalid -- - Key: TUSCANY-1478 URL: https://issues.apache.org/jira/browse/TUSCANY-1478 Project: Tuscany Issue Type: Bug Components: C++ SDO Environment: all Reporter: Michael Yoder Attachments: TUSCANY-1478.txt This appears to be a regression in XML serialization. The SCA CppBigBank example is currently failing to get a response from the StockQuote service due to sending an invalid request. Using the XML Schema embedded in StockQuoteService.wsdl, the following code: DataFactoryPtr mdg = DataFactory::getDataFactory(); XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg); xsh-defineFile(StockQuoteService.wsdl); DataObjectPtr doObj = mdg-create(http://swanandmokashi.com;, GetQuotes); doObj-setCString(QuoteTicker, IBM); XMLHelperPtr xmlHelper = HelperProvider::getXMLHelper(mdg); XMLDocumentPtr doc = xmlHelper-createDocument(doObj, http://swanandmokashi.com;, GetQuotes); xmlHelper-save(doc, out.xml); Will produce the invalid instance document: ?xml version=1.0 encoding=UTF-8? tns:GetQuotes xmlns:tns=http://swanandmokashi.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;QuoteTickerIBM /QuoteTicker/tns:GetQuotes The element QuoteTicker should be namespace qualified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [LDAP DAS] Current API and EMF dependencies...
SNIP Good, I'll wait for your updates to take a further look. Please let me know when you committ these updates. Cool - I'll check in and update in a few days. SNIP I have no idea of when SDO 3.0 will be available, and we are not sure that we will have all the necessary APIs you think is missing on that release, right ? Sure - I'm sure 3.0 vs. 2.1 will be a minor thing overall. Once I'm done with the design document, we can review and consider an approach for the gaps that we see between the APIs. There are something like 12 classes that use EMF, of which 6 are core classes, so I think solutions to make the LDAP DAS SDO 2.1 compliant can be implemented quickly. SNIP We should also involve the SDO folks here, and get their input on this subject, but, having RDB DAS and LDAP DAS returning incompatible SDO would be a issue to really take in consideration when making the final decision here. Sure - I think once we understand the gaps, we'll quickly come up with solutions, and then we can put them all in a road map, and start making the LDAP DAS work with the SDO Spec. SNIP This is not really around SDO, but making usage of DAS Interfaces. I'd expect that the LDAP DASImpl [1] would implement a variation of Tuscany DAS Interface [2], and all other Tuscany DAS implementations would do the same (e.g RDB, XQuery, or any other that comes in the future). A similar interface is being used for DAS C++. This allows for a common programming model and api on the DAS level. Any plans for this ? Yes - That's the plan. [1] https://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.ldap.parent/das.ldap/src/main/java/org/apache/tuscany/das/ldap/impl/DASImpl.java [2] https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/das/api/src/main/java/org/apache/tuscany/das/DAS.java - 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: Synapse using SCA assembly model for configuration
Paul, Great to hear from you! Some thoughts inline. Paul Fremantle wrote: I recently read Dan's blog entry on the SCA assembly model: http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ That and some other discussions I've had made me think about maybe offering the SCA assembly model to configure Synapse. So it seems to me that you can draw a direct correlation between: Synapse Proxy and SCA Service Synapse Endpoint and SCA reference Synapse Mediator - a specific type of SCA Component Synapse Property - SCA Property It certainly looks like a reasonable mapping. If we were to make the XMLConfigurationBuilder pluggable then we could just use this as an alternative configuration language. We did talk about this in the beginning of Synapse [we discussed having a LEX/YACC style config language - which I would still LOVE if someone wants to do that - it would make a great Computer Science project] Anyway back to SCA, it seems to me that this would be a pretty nice alternative config model, using an independent third party language. I'm guessing that there is plenty of Tuscany code could help us implement this. Maybe we might do it jointly? So I'm imagining the existing runtime being *exactly* the same as today, but being able to use a subset of the SCA Assembly model to configure it. Maybe some of the SCA wizards on tusc-dev can jump in and let me know if this is feasible? SCA makes no assumption about the runtime at all - and the spec teams have always viewed the SCA model as being mappable to a whole range of runtimes, so this way of thinking about things is fine. Indeed, some of the work in the Eclipse tools project is done this way, where an SCA model is used to describe the solution in the tools and is then mapped to the configuration file format of a particular runtime. The runtime never sees the SCA metadata directly. Your idea is to do this mapping at runtime - I happen to prefer that way of doing things. One BIG question to ask is whether you want to support implementation artifacts with SCA annotations. SCA supports, for example, Java classes with annotations which configure them with a range of features - this is an alternative to providing the information in the SCA XML format. Doing this requires appropriate introspector code in the runtime. This can certainly come from Tuscany. Paul PS If someone is looking at http://www.infoq.com/news/2007/07/scaproblem and wondering where this is coming from I offer a few thoughts. Firstly, I'm always open to being proved wrong! Secondly, this would not be adding any layers of indirection... I'm mapping directly from SCA concepts into the Synapse runtime with this idea. Finally, I see nothing wrong with holding several inconsistent viewpoints at the same time :) This direct mapping of SCA metadata into runtime entities is behind my contention that SCA does not add any layering. SCA is not about indirection, rather it is about having a consistent way of describing SOA configuration, which is mapped to the specifics of given component and runtime technologies. Only where it is the intention to extend the runtime(s) involved (eg with support for new bindings) would there need to be any consideration of layering - but then it is a question of how the runtime itself is written - the ideal is no layering, but a simple addition of function. As for holding multiple inconsistent viewpoints at once - politicians seem to manage that as a way of life ;-) Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid
I'm looking at it right now! On 25/07/07, Michael Yoder [EMAIL PROTECTED] wrote: Hi, I uploaded a patch for C++ SDO which fixes its XML serialization to produce XML valid against schemas with elementFormDefault=true. If someone could verify and apply it that would be great. This gets the SCA sample CppBigBank working again. Thanks, Michael Rogue Wave Software, Inc. - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 24, 2007 2:22 PM To: tuscany-dev@ws.apache.org Subject: [jira] Updated: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid [ https://issues.apache.org/jira/browse/TUSCANY-1478?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1478: --- Attachment: TUSCANY-1478.txt This patch resolves the issue and adds a unit test. For schemas with elementFormDefault=true, serialized instance documents are invalid -- - Key: TUSCANY-1478 URL: https://issues.apache.org/jira/browse/TUSCANY-1478 Project: Tuscany Issue Type: Bug Components: C++ SDO Environment: all Reporter: Michael Yoder Attachments: TUSCANY-1478.txt This appears to be a regression in XML serialization. The SCA CppBigBank example is currently failing to get a response from the StockQuote service due to sending an invalid request. Using the XML Schema embedded in StockQuoteService.wsdl, the following code: DataFactoryPtr mdg = DataFactory::getDataFactory(); XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg); xsh-defineFile(StockQuoteService.wsdl); DataObjectPtr doObj = mdg-create(http://swanandmokashi.com;, GetQuotes); doObj-setCString(QuoteTicker, IBM); XMLHelperPtr xmlHelper = HelperProvider::getXMLHelper(mdg); XMLDocumentPtr doc = xmlHelper-createDocument(doObj, http://swanandmokashi.com;, GetQuotes); xmlHelper-save(doc, out.xml); Will produce the invalid instance document: ?xml version=1.0 encoding=UTF-8? tns:GetQuotes xmlns:tns=http://swanandmokashi.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;QuoteTickerIBM /QuoteTicker/tns:GetQuotes The element QuoteTicker should be namespace qualified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1478) For schemas with elementFormDefault=true, serialized instance documents are invalid
[ https://issues.apache.org/jira/browse/TUSCANY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Robbins resolved TUSCANY-1478. --- Resolution: Fixed Fix Version/s: Cpp-Next Patch applied to HEAD and the sdo-cpp-pre2.1 branch For schemas with elementFormDefault=true, serialized instance documents are invalid --- Key: TUSCANY-1478 URL: https://issues.apache.org/jira/browse/TUSCANY-1478 Project: Tuscany Issue Type: Bug Components: C++ SDO Environment: all Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1478.txt This appears to be a regression in XML serialization. The SCA CppBigBank example is currently failing to get a response from the StockQuote service due to sending an invalid request. Using the XML Schema embedded in StockQuoteService.wsdl, the following code: DataFactoryPtr mdg = DataFactory::getDataFactory(); XSDHelperPtr xsh = HelperProvider::getXSDHelper(mdg); xsh-defineFile(StockQuoteService.wsdl); DataObjectPtr doObj = mdg-create(http://swanandmokashi.com;, GetQuotes); doObj-setCString(QuoteTicker, IBM); XMLHelperPtr xmlHelper = HelperProvider::getXMLHelper(mdg); XMLDocumentPtr doc = xmlHelper-createDocument(doObj, http://swanandmokashi.com;, GetQuotes); xmlHelper-save(doc, out.xml); Will produce the invalid instance document: ?xml version=1.0 encoding=UTF-8? tns:GetQuotes xmlns:tns=http://swanandmokashi.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;QuoteTickerIBM/QuoteTicker/tns:GetQuotes The element QuoteTicker should be namespace qualified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1477) CompositeActivatorImpl.deactivate() is empty
[ https://issues.apache.org/jira/browse/TUSCANY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515341 ] Raymond Feng commented on TUSCANY-1477: --- Hi, Can you elaborate a bit more on the problem? For example, stacktrace or the sympton such as the components are not removed as expected? When I look into the code, EmbeddedSCADomain.DomainCompositeHelper.removeComposite() removes the composite from the SCA domain composite in addtion to calling compositeActivator.deactivate(). Thanks, Raymond CompositeActivatorImpl.deactivate() is empty Key: TUSCANY-1477 URL: https://issues.apache.org/jira/browse/TUSCANY-1477 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.91 Reporter: Vamsavardhana Reddy CompositeActivatorImpl.deactivate() is empty. Should there be some code in there? I am seeing a problem with removing components and composites from EmbeddedSCADomain. I have called EmbeddedSCADomain.DomainCompositeHelper ().stopComponent() with all the component names in my composite and then EmbeddedSCADomain.DomainCompositeHelper ().removeComposite(). I am noticing that the components are not getting removed from EmbeddedSCADomain.domainComposite. EmbeddedSCADomain.DomainCompositeHelper.removeComposite() is calling compositeActivator.deactivate(). But CompositeActivatorImpl.deactivate() is empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1477) CompositeActivatorImpl.deactivate() is empty
[ https://issues.apache.org/jira/browse/TUSCANY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515348 ] Luciano Resende commented on TUSCANY-1477: -- One of the issues here is that there is no implementation for CompositeActivatorImpl.deactivate() Some more information available on the following threads : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20596.html http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20674.html CompositeActivatorImpl.deactivate() is empty Key: TUSCANY-1477 URL: https://issues.apache.org/jira/browse/TUSCANY-1477 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.91 Reporter: Vamsavardhana Reddy CompositeActivatorImpl.deactivate() is empty. Should there be some code in there? I am seeing a problem with removing components and composites from EmbeddedSCADomain. I have called EmbeddedSCADomain.DomainCompositeHelper ().stopComponent() with all the component names in my composite and then EmbeddedSCADomain.DomainCompositeHelper ().removeComposite(). I am noticing that the components are not getting removed from EmbeddedSCADomain.domainComposite. EmbeddedSCADomain.DomainCompositeHelper.removeComposite() is calling compositeActivator.deactivate(). But CompositeActivatorImpl.deactivate() is empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Hi, If I understand the SCA assembly spec correctly, the SCA resolution mechanism will be used when the schemaLocation is not present. For example, let's assume a.xsd has an import statement as follows: import namespace=http://ns1/ We're going to use the namespace (http://ns1) as the key to find the matching schema (which contains the type/element definitions referenced by a.xsd) from another artifact(s). Thanks, Raymond - Original Message - From: Mike Edwards [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 25, 2007 6:33 AM Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers? Raymond, How does this relate to the contribution resolution mechanism described by the SCA specifications? Yours, Mike. Raymond Feng wrote: Hi, We currently use XmlSchema to load XSDs. To resolve the import/include directives using our schemes, we provide an implementation of org.apache.ws.commons.schema.resolver.URIResolver and set it to org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the schemaLocation attribute for the xsd:import or xsd:include is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, xsd:import namespace=http://ns1/. Without the schemaLocation, we resolve the import/include by namespace. In this case, we already have a map keyed by namespace for a list of XmlSchema objects loaded from a catalog or other files and we want to reuse them. Would it be possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that we can override/customize the behavior to associate existing XmlSchema instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to keep the schema map is not always feasible. Another observation is that a NPE will be thrown if the URIResolver.resolveEntity() returns null. Is there any way to disable the aggressive resolving/loading of import/include? [EMAIL PROTECTED] Raymond Feng Apache Tuscany - 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]
[jira] Created: (TUSCANY-1480) Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders services from previous contribution unusable
Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders services from previous contribution unusable Key: TUSCANY-1480 URL: https://issues.apache.org/jira/browse/TUSCANY-1480 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.91 Reporter: Vamsavardhana Reddy Here is a situation I am running into. Step 0: Create an EmbeddedSCADomain. Step 1: Add contribution from contribution1.jar (which provides say Service1) to EmbeddedSCADomain from Step 0. Step 2: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain() Step 3: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all componets from contribution1.jar. Step 4: Add contribution from contribution2.jar (which provides say Service2) to EmbeddedSCADomain from Step 0. Step 5: Call EmbeddedSCADomain.DomainCompositeHelper.activateDomain() Step 6: Call EmbeddedSCADomain.DomainCompositeHelper.startComponent() on all componets from contribution2.jar. After Step 3, I am able to run Service1 successfully. At Step 5, I get a message like the following: Composite assembly problem: Service not found for component service: CalculatorServiceComponent/$promoted$.CalculatorService After Step 6, Service1 no longer runs, where as Service2 runs successfully. If I call DomainCompositeHelper.startComponent() on each of the components from the first contribution after deploying the second, (that is after Step 6 from), it results in an Exception which I ignore and continue. But towards the end I have services from both contributions running successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1438: --- Attachment: tuscany_patch_update5_jira1438 Uploading patch update 5 which includes: - runtime/extensions/php/build.xml - minor change to php code so that it compiles - compile-targets.xml added cpp-link-core which does not link in the tuscany_sca lib and changed cpp-link so that it does link it in. Change TuscanySCA Native build system to use ant Key: TUSCANY-1438 URL: https://issues.apache.org/jira/browse/TUSCANY-1438 Project: Tuscany Issue Type: Improvement Components: C++ SCA Affects Versions: Cpp-Next Environment: all platforms Reporter: Brady Johnson Priority: Minor Fix For: Cpp-Next Attachments: tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, tuscanySCAnative_ant.tar.gz, tuscanySCAnative_ant_update1.tar.gz In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1353: - Affects Version/s: Java-DAS-Next Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2, Java-DAS-Next Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Assignee: Amita Vadhavkar Priority: Critical Fix For: Java-DAS-Next Attachments: 1353.patch, 1353.patch Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release process guide checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Let me come up with some initial document over the weekend, and we could start providing feedback on top of that, also we could check if there is going to be any value on that or not. On 7/25/07, ant elder [EMAIL PROTECTED] wrote: As an example of how much simpler things could be if we got our maven builds set up so maven automated everything see: http://incubator.apache.org/cxf/building.html#Building-Performingarelease But, I still think a RM should understand whats going on so mvn shouldn't be a substitute for having read all the ASF and Incubator doc about releases. ...ant On 7/25/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I'd like the release guide if the steps we follow are a bit different than what is normally done or if there are some variations to how we perform some steps. But if we were just about going to rephrase all of what has already been said somewhere else I'd prefer just about having a pointer from Tuscany. Maybe a good begining to all of this could be to have our release guide and link to the information that is available. Then as we get to review and apply that we could flesh our guide. Having said that, I'd like us to have a 'release review checklist' that enlists the bunch of things that need to be reviewed in a RC including things like testing out the binary distro before the source distro. etc. - Venkat On 7/24/07, Simon Laws [EMAIL PROTECTED] wrote: snip.. There's already lots of doc about doing releases in the ASF - on the ASF main dev pages and within the Incubator site etc. The problem with there being lots of docs is that there are, ahem, lots of docs. Where is the definitive set of guides that provide the detail required to release Tuscany for someone, like me, who hasn't done it before? Possibly an impossible question to answer as you don't know what I don't know and I don't know what you do know so our view of what is an acceptable level of detail probably differs. Here are the top level guides I found. http://www.apache.org/dev/#rreleases http://incubator.apache.org/guides/releasemanagement.html I can't say whether the above links are satisfactory as I haven't been through the process but I agree that we should propose updates if they are found to be wanting. For example, a discussion of RAT. For consistency I would expect to see all the keystrokes recorded that are required to produce and distribute a release. The fewer the better so, yes, more automation would be good. I expect automation does not completely remove the responsibility to check the release against release criteria, e,g, legal, but gives a good indication of what is required to make the release happen. Again anything we can do to automate these checks is good. I don't expect that release is a process that should involve a lot of imagination on our part other than in providing more automation of the required steps. To put it another way is there anything specific we have to do for Tuscany that would not be included in the general guide? I note that many projects do have release guides. Why is this the case? http://httpd.apache.org/dev/release.html http://cayenne.apache.org/release-guide.html http://incubator.apache.org/servicemix/release-guide.html http://activemq.apache.org/release-guide.html I do note that the Incubator release guide states Different options or opinions are encouraged.. If options are offered (and I can't say that there are without reading the detail) then we need a place to document which are chosen for Tuscany releases. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1481) TuscanyServlet looks for servlets using path info and not the whole path
TuscanyServlet looks for servlets using path info and not the whole path
-
Key: TUSCANY-1481
URL: https://issues.apache.org/jira/browse/TUSCANY-1481
Project: Tuscany
Issue Type: Bug
Components: Java SCA Web App Integration
Affects Versions: Java-SCA-Next
Environment: All
Reporter: Simon Laws
In the TuscanyServlet service method there is code to find a registerest servlet
String path = ((HttpServletRequest)req).getPathInfo();
Servlet servlet = servletHost.getServlet(path);
if (servlet == null) {
throw new IllegalStateException(No servlet registered for
path: + path);
}
Currently though in the code servlets can get registered against full path
names, e,g, when the full path name is defined in WSDL, and hence the servlet
is not found. I expect it is this way as its not expecting a full path to be
specified. Why would it, the application is deployed into an already running
app server. We either need to raise an error to tell people why their services
can't be found or check for full path names.
I've dont the latter for now (see the change assoicated with this JIRA) but
would welcome some more thought on this issue as I expect the is a good reason
why it is this way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Weird maven behavior during local SCA build.
If I remove o.a.tuscany/sca from my local maven repository, and then try to build SCA, I'm having all weired issues around missing dependencies from artifacts that are supposed to get built during the build I'm executing. I also noticed that maven is resolving some other artifacts to its published SNAPSHOT, instead of the one that is supposed to get built. I tried in two machines and can reproduce the error, the same way, in both... Below are some of the missing dependencies... but the first one to fail for me is implementation-notification, also note that, if you go and build it manually, then you can progress further, until when maven feel bad about some other dependencies... Any suggestions ? Ideas ? Missing: -- 1) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-distributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ing-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT -- 2 required artifacts are missing. for artifact: org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT from the specified remote repositories: 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) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 21 seconds [INFO] Finished at: Wed Jul 25 16:59:30 PDT 2007 [INFO] Final Memory: 19M/35M [INFO] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Hi, Raymond, We encountered the same problem when implementing SDO's XSDHelper. Where we used EMF's xsd tool package for resolve xsd. Wherein we just implemented our own XSDSchemaLocator and added it to the resource's adapters, then we can do everything in locating the import/include xsd. It works fine. I don't know if XmlSchema have any thing alike. - Original Message - From: Mike Edwards [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, July 25, 2007 9:33 PM Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers? Raymond, How does this relate to the contribution resolution mechanism described by the SCA specifications? Yours, Mike. Raymond Feng wrote: Hi, We currently use XmlSchema to load XSDs. To resolve the import/include directives using our schemes, we provide an implementation of org.apache.ws.commons.schema.resolver.URIResolver and set it to org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the schemaLocation attribute for the xsd:import or xsd:include is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, xsd:import namespace=http://ns1/. Without the schemaLocation, we resolve the import/include by namespace. In this case, we already have a map keyed by namespace for a list of XmlSchema objects loaded from a catalog or other files and we want to reuse them. Would it be possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that we can override/customize the behavior to associate existing XmlSchema instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to keep the schema map is not always feasible. Another observation is that a NPE will be thrown if the URIResolver.resolveEntity() returns null. Is there any way to disable the aggressive resolving/loading of import/include? [EMAIL PROTECTED] Raymond Feng Apache Tuscany - 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: Weird maven behavior during local SCA build.
I ran into problems where the plugin requests for one version of the artifact but gets back a different version of the artifact. Something like... Searching for commonj/sdo- api-r2.1/1.0-incubating-SNAPSHOT/jar at http://people.apache.org/repo/m2-incubating-repository Downloading commonj/sdo-api-r2.1/1.0-incubating-beta1/jar... Do you think it is similar to the problem you are seeing? Vamsi On 7/26/07, Luciano Resende [EMAIL PROTECTED] wrote: This might be something related to new versions of some maven plugins as I was able to find an old version of the repository, and I was able to build from that ok. So, maybe it's not a good idea to clean your repo or use a mvn -U right now. On 7/25/07, Luciano Resende [EMAIL PROTECTED] wrote: If I remove o.a.tuscany/sca from my local maven repository, and then try to build SCA, I'm having all weired issues around missing dependencies from artifacts that are supposed to get built during the build I'm executing. I also noticed that maven is resolving some other artifacts to its published SNAPSHOT, instead of the one that is supposed to get built. I tried in two machines and can reproduce the error, the same way, in both... Below are some of the missing dependencies... but the first one to fail for me is implementation-notification, also note that, if you go and build it manually, then you can progress further, until when maven feel bad about some other dependencies... Any suggestions ? Ideas ? Missing: -- 1) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId= org.apache.tuscany.sca -DartifactId=tuscany-distributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ing-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT -- 2 required artifacts are missing. for artifact: org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT from the specified remote repositories: 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 ) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 21 seconds [INFO] Finished at: Wed Jul 25 16:59:30 PDT 2007 [INFO] Final Memory: 19M/35M [INFO] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird maven behavior during local SCA build.
This might be something related to new versions of some maven plugins as I was able to find an old version of the repository, and I was able to build from that ok. So, maybe it's not a good idea to clean your repo or use a mvn -U right now. On 7/25/07, Luciano Resende [EMAIL PROTECTED] wrote: If I remove o.a.tuscany/sca from my local maven repository, and then try to build SCA, I'm having all weired issues around missing dependencies from artifacts that are supposed to get built during the build I'm executing. I also noticed that maven is resolving some other artifacts to its published SNAPSHOT, instead of the one that is supposed to get built. I tried in two machines and can reproduce the error, the same way, in both... Below are some of the missing dependencies... but the first one to fail for me is implementation-notification, also note that, if you go and build it manually, then you can progress further, until when maven feel bad about some other dependencies... Any suggestions ? Ideas ? Missing: -- 1) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-distributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ributed \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-distributed:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany.sca -DartifactId=tuscany-binding-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apa ing-jms \ -Dversion=1.0-incubating-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT 2) org.apache.tuscany.sca:tuscany-binding-jms:jar:1.0-incubating-SNAPSHOT -- 2 required artifacts are missing. for artifact: org.apache.tuscany.sca:tuscany-binding-sca:jar:1.0-incubating-SNAPSHOT from the specified remote repositories: 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) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 21 seconds [INFO] Finished at: Wed Jul 25 16:59:30 PDT 2007 [INFO] Final Memory: 19M/35M [INFO] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dynamic Type Definition...
I think the problem is that when you set many=true then the attribute becomes a list rather than a bare type (otherwise there is no way to add multiple attributes). You need to do: Listint custNum = new ArrayList(); custNum.add(1000); createdDO.setList(custNum, custNum); I didn't see the custNum element in your XSD so I don't know if you want to do the above or remove the many=true property. Dean. -Original Message- From: Upeka Bulumulle [mailto:[EMAIL PROTECTED] Sent: Thursday, 26 July 2007 4:21 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Dynamic Type Definition... Hi All, Tuscany SDO version: Tuscany SDO 1.0 beta1. I'm trying to dynamically create and use types without the use of an XSD file. What i want to do is something a little different to what is described in the samples provided. I want to have elements within each nested type. i also want to to be able to support lists (String lists, Interger lists etc). My dynamically defined XSD should look like this (complete xsd is attached...), xsd:element name=dataType type=DataType/ xsd:complexType name=DataType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=item type=ItemType/ xsd:element maxOccurs=unbounded minOccurs=0 name=list type=ListItemType/ /xsd:sequence /xsd:complexType xsd:complexType name=ItemType xsd:sequence xsd:element name=type type=xsd:string/ xsd:element name=name type=xsd:string/ xsd:element name=boolean type=xsd:boolean/ /xsd:sequence xsd:complexType name=ListItemType xsd:sequence xsd:element name=listType type= xsd:string/ xsd:element name=listName type= xsd:string/ xsd:element name=booleanList type= BooleanListType/ /xsd:sequence /xsd:complexType xsd:complexType name=BooleanListType xsd:sequence xsd:element maxOccurs=unbounded minOccurs= 0 name=booleanValue type=xsd:boolean/ /xsd:sequence /xsd:complexType I added the many true option when creating the property for each data object which resulted in type, name and boolean resulting in elements. // create data graph root DataGraph dataGraph = SDOUtil.createDataGraph(); DataObject dynamic = dataGraph.createRootObject(commonj.sdo, Type); dynamic.set(uri, http://www.dynamic.com/dynamic ); dynamic.set(name, DataType); dynamic.set(dataType, false); // primitive type.. ints DataObject custNumProperty = dynamic.createDataObject (property); custNumProperty.set(name, custNum); custNumProperty.set(type, intType); custNumProperty.set(many, true); However i am unable set values to the data object once i do this.I get the following stack trace when i do this, DataObject createdDO = DataFactory.INSTANCE.create(http://www.dynamic.com/dynamic;, DataType); createdDO.setInt(custNum, 1000); java.lang.ClassCastException: java.lang.Integer at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegat eM any.dynamicSet (EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl .j ava:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDat aO bjectImpl.java :150) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1442 ) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:6 54 ) at org.apache.tuscany.sdo.impl.DataObjectImpl.set (DataObjectImpl.java:143) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:53 2) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:52 6) (if i leave out the many true flag, then the xsd displays them as attributes and i am able to set values to them) My code is attached for your review. I would appreciate your help in this regard. The reason i want to dynamically define the type is because my client requires high performant code. The time taken to execute the dynamic xsd is quite less compared to the time taken to read the xsd. Almost a whole second. Thanks and regards Roshan The samples provide an example where the dynamically defined types result in attributes and not elements. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Normalize the reference endpoints for bindings
Hi, This email thread has stopped, but I'll revive it...comments here. WRT the tables on the wiki, everything looks good except: -Table 2, row 1, I think the binding should be binding.sca. I don't think the spec is clear on this and thus there will be disagreement. -Table 2, row2, I think there is one wire, no multiplicity violation. -Table 2, row4, ok, but I think you will need a unique name for each binding.sca. Dave - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 17, 2007 5:18 PM Subject: Re: Normalize the reference endpoints for bindings Comments inline. Simon Jean-Sebastien Delfino wrote: Comments inline. Raymond Feng wrote: Hi, As captured at http://cwiki.apache.org/TUSCANYWIKI/multiple-bindings-and-reference-multiplicity.html, a reference can use target attribute or binding uri to declare the outbound endpoints. Multiplicity and promotion complicate the picture even more. I'd like others familiar with the spec to review this table too, but it looks good to me. It looks good to me, but I am a bit surprised by the second row of the promotion table. Why is this invalid and does not override the lower-level target? I would have expected the override. I suggest that we internally (for example, in CompositeBuilderImpl) normalize the reference bindings as illustrated by column 4 of the tables in the wiki page. Then the runtime can follow the two simple rules: Rule #1. Binding with a specified endpoint = a wire Rule #2. Multiplicity is about the number of wires allowed for the reference +1 for normalizing reference bindings as you suggest. +1 from me too but I would do it in a slightly different way as follows: In the SCDL: reference name=R1 target=C2/S1 C3/S1 binding.x/ /reference Normalized: reference name=R1 binding.x wire uri=C2/S1/ wire uri=C3/S1/ /binding.x /reference Interesting. It's not valid SCDL syntax but I get the jist of the idea. It might require we add something such as resolvedEndpoint to the Binding interface (leaving the uri attribute to host the value from SCDL). For SCA reference binding, the resolvedEndpoint could be the Component/ComponentService. I don't know why the core wiring framework needs to obtain this value. It needs to know whether or not the binding has a resolved endpoint because the target attribute would then be invalid, but I don't think it needs to know the value of the endpoint. I think we can update the URI attribute in place like we already do for many other cases where we normalize or compile the assembly model. Having two different attributes would create confusion on how to use these two attributes and when to set one or the other when you construct an in-memory model. I am uncomfortable with this because 1) it may not be possible in all cases to express all the binding endpoint information as a single URI string 2) I don't know why this is is needed. I would expect the binding to be able to manage its own endpoint information in a binding-specific way (see above) 3) this forces the use of cloned bindings to handle the case of multiple targets. I don't think bindings should be cloned for this case (see below). To handle multiplicity, I think we should clone bindings (one per target), as opposed to maintaining a list of target endpoints on a binding. I'm concerned about this because of the difficulty with naming the cloned bindings. Each binding on a service or reference must have a unique name. If the cloned binding has a different name, this violates what was specified in the SCDL. If it has the same name, this violates the unique naming rule. See my example above for an alternative way of doing the normalization. Finally, looking at how the SCA binding works now, I propose the following changes: - remove or deprecate the component field (which was a hack, it's time to clean it up) +1 - add a targetBinding field pointing to the SCABinding on the target service I'm not sure why this is needed. What is not currently working in the code that requires this to be added? Would this just be for local SCABindings, or for remote SCABindings as well? What do you guys think? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1353: - Fix Version/s: Java-DAS-Next Patch Info: [Patch Available] Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2, Java-DAS-Next Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Assignee: Amita Vadhavkar Priority: Critical Fix For: Java-DAS-Next Attachments: 1353.patch, 1353.patch Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release SDO Java version 1.0-incubating
Please review and vote to release the 1.0-incubating distribution of Tuscany SDO for Java The release candidate RC3 for Tuscany Java SDO archive distribution files are posted at [1] The release audit tool (rat) files and associated exceptions are posted at [1] also The maven repository artifacts are posted in a staging repository [2] http://people.apache.org/%7Ekelvingoodson/sdo_java/M3/RC2/The tag for the source code is at [3] The release notes for this release are attached below Changes to this release candidate from the RC2 candidate The SDO API jar file includes LICENSE, NOTICE and DISCLAIMER files The LICENSE and NOTICE files in other projects have been cleaned up to remove unnecessary references and to conform to current Apache standards The artifacts in the staging repo have been signed The sample artifacts have been removed from the staging repo The test classes in the tools project have been regenerated The tools pom has been commented to avoid confusion over the asm dependency The use of the 0.8-SNAPSHOT version of the maven-osgi-plugin has not been altered as there is no update to this plugin It looks OK to me so here's my +1 Regards, Kelvin. [1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC3/ [2] http://people.apache.org/~kelvingoodson/repo/org/apache/tuscany/sdo/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.0-incubating/ = Service Data Objects (SDO) Java version 1.0-incubating Release Notes The Service Data Objects (SDO) API simplifies and unifies Service Oriented Architecture (SOA) data access and code. SDO offers both a static and a dynamic programming model for data access. Choosing to generate static classes to repreent your data model gives you the ease and intuitive nature of the static programming model, backed up by the power of the dynamic model too. SDO also offers the capacity to track changes to data. If a graph of data includes a change summary property, then additions, modifications, and deletions made to the graph within the scope of that change summary will be recorded. What's new in this Release == Apache Tuscany's SDO Java Release 1.0-incubating is the first such release with full coverage of the SDO 2.1 specification. In addition to adding the few remaining SDO 2.1 features not included in the 1.0-incubating-beta1 release and fixing a number of bugs (see below for detail) there are a number of new features relating to XML serialization, and new support for handling dynamic derivation from static classes. There has also been significant focus on making the SDO sample programs more accessible. For previous revision history, take a look at http://svn.apache.org/viewvc/incubator/tuscany/tags/java/sdo/1.0-incubating-beta1/sdo/distribution/RELEASE_NOTES.txt SDO Java 1.0-incubating is a superset of previous SDO 1.0-incubating-beta1release. Anything in 1.0-incubating-beta1 is also in 1.0-incubating, but 1.0-incubating contains features and bugfixes not present in 1.0-incubating-beta1 release. Downloading === Please visit http://incubator.apache.org/tuscany/sdo-java-releases.html Binary Artifact Changes === PLEASE NOTE that Since the 1.0-incubating-beta release the following binary artifacts have been renamed The maven groupId of the SDO API binary artifact has changed from commonj to org.apache.tuscany.sdo The maven artifactId for the SDO API binary artifact has changed from sdo-api-r2.1 to tuscany-sdo-api-r2.1 The jar file containing the SDO API has a new tuscany- prefix, so what was .. sdo-api-r2.1-1.0-incubating-beta1.jar in the beta1 release becomes tuscany-sdo-api-r2.1-1.0-incubating.jar in this release. In addition a new maven artifact and jar has appeared. maven groupId=org.apache.tuscany.sdo maven artifactId=tuscany-sdo-lib jar archive=tuscany-sdo-lib-1.0-incubating This artifact provides a cleear distinction between Tuscany SDO implementation, and the Tuscany API which extends the SDO API. See the javadoc contained in the binary release for details of the function provded by this artifact. New Features and Fixes == For more detail on these fixes and features please see ... https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210fixfor=12312521resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC New Feature TUSCANY-1213SDO 2.1 feature: DataHelper.convert() TUSCANY-1212SDO 2.1 feature: Property.isNullable() and Property.isOpenContent() TUSCANY-1214SDO 2.1 feature: XMLHelper.load(Source) and XMLHelper.save(Result) TUSCANY-1197Sequence composition TUSCANY-1317Provide a way to set default XML load options to be used during Java deserialization Improvement TUSCANY-1350Reorganise SDO build / distribution layout TUSCANY-1459Remove package
[jira] Resolved: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1353. -- Resolution: Fixed Patch applied under revision #559580. Thanks Amita. Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2, Java-DAS-Next Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Assignee: Amita Vadhavkar Priority: Critical Fix For: Java-DAS-Next Attachments: 1353.patch, 1353.patch Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1482) CompositeProcessor does not write out Property objects completely
CompositeProcessor does not write out Property objects completely - Key: TUSCANY-1482 URL: https://issues.apache.org/jira/browse/TUSCANY-1482 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Reporter: Brent Daniel CompositeProcessor will write out a Property with its name, but will ignore other attributes such as source, many, or must supply. This is true of both component properties and composite properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r559546 - /incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/
Hi,
For those who are interested in the JMS binding, I just checked in a set of
interfaces for the model defined by the SCA JMS Binding Spec 1.0.
Feedback and help are appreciated.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 25, 2007 11:12 AM
Subject: svn commit: r559546 -
/incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/
Author: rfeng
Date: Wed Jul 25 11:12:21 2007
New Revision: 559546
URL: http://svn.apache.org/viewvc?view=revrev=559546
Log:
A strawman of interfaces for the model defined by the SCA JMS Binding Spec
1.0
Added:
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ConnectionFactory.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ConnectionInfo.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/CorrelationScheme.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/CreateResource.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/Definitions.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/Destination.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/DestinationType.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/Headers.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/JMSBinding.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/JMSBindingFactory.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/OperationProperties.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/Property.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/PropertyList.java
(with props)
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ResourceAdapter.java
(with props)
Added:
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java?view=autorev=559546
==
---
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java
(added)
+++
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java
Wed Jul 25 11:12:21 2007
@@ -0,0 +1,30 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.tuscany.sca.binding.jms.model;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public interface ActivationSpec extends PropertyList {
+String getName();
+void setName(String name);
+CreateResource getCreate();
+void setCreate(CreateResource create);
+}
Propchange:
incubator/tuscany/java/sca/modules/binding-jms/src/main/java/org/apache/tuscany/sca/binding/jms/model/ActivationSpec.java
--
svn:eol-style = native
Propchange:
[SCA Native] SCA Build error on Linux, was: SDO Build error on Linux
Jean-Sebastien Delfino wrote: Pete Robbins wrote: Works fine on all our linuxes including my RHEL... I've removed the unnecessary qualifier so you should be fine now. Cheers, Thanks Pete, I just updated from SVN, I'm flying to Portland today as I'm going to the OSCON conference, I'll try again from the airport :) I tried again, it now goes further and fails with the following: Making install in reference make[4]: Entering directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference' Making install in curl make[5]: Entering directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference/curl' Making install in src make[6]: Entering directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference/curl/src' /bin/sh ../../../../../../libtool --tag=CXX --mode=link g++ -g -O0 -o libtuscany_sca_rest_reference.la -rpath /home/delfinoj/Tuscany/apache-deploy/cpp/sca/extensions/rest/reference/lib RESTServiceBindingExtension.lo RESTServiceBinding.lo RESTServiceWrapper.lo -L/home/delfinoj/Tuscany/apache-deploy/cpp/sdo/lib -ltuscany_sdo -L../../../../../../runtime/core/src -ltuscany_sca -L../../../../../../runtime/extensions/rest/interface/src -ltuscany_sca_rest_interface -L/home/delfinoj/Tuscany/curl/curl-7.15.5-bin/lib -lcurl grep: /usr/lib/libidn.la: No such file or directory /bin/sed: can't read /usr/lib/libidn.la: No such file or directory libtool: link: `/usr/lib/libidn.la' is not a valid libtool archive make[6]: *** [libtuscany_sca_rest_reference.la] Error 1 make[6]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference/curl/src' make[5]: *** [install-recursive] Error 1 make[5]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference/curl' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest/reference' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions/rest' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime/extensions' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/delfinoj/Tuscany/apache-repos/cpp/sca/runtime' make: *** [install-recursive] Error 1 What's libidn.la used for? Any idea? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic Type Definition...
Hi All, Tuscany SDO version: Tuscany SDO 1.0 beta1. I'm trying to dynamically create and use types without the use of an XSD file. What i want to do is something a little different to what is described in the samples provided. I want to have elements within each nested type. i also want to to be able to support lists (String lists, Interger lists etc). My dynamically defined XSD should look like this (complete xsd is attached...), xsd:element name=dataType type=DataType/ xsd:complexType name=DataType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=item type=ItemType/ xsd:element maxOccurs=unbounded minOccurs=0 name=list type=ListItemType/ /xsd:sequence /xsd:complexType xsd:complexType name=ItemType xsd:sequence xsd:element name=type type=xsd:string/ xsd:element name=name type=xsd:string/ xsd:element name=boolean type=xsd:boolean/ /xsd:sequence xsd:complexType name=ListItemType xsd:sequence xsd:element name=listType type= xsd:string/ xsd:element name=listName type= xsd:string/ xsd:element name=booleanList type= BooleanListType/ /xsd:sequence /xsd:complexType xsd:complexType name=BooleanListType xsd:sequence xsd:element maxOccurs=unbounded minOccurs= 0 name= booleanValue type=xsd:boolean/ /xsd:sequence /xsd:complexType I added the many true option when creating the property for each data object which resulted in type, name and boolean resulting in elements. // create data graph root DataGraph dataGraph = SDOUtil.createDataGraph(); DataObject dynamic = dataGraph.createRootObject(commonj.sdo, Type); dynamic.set(uri, http://www.dynamic.com/dynamic ); dynamic.set(name, DataType); dynamic.set(dataType, false); // primitive type.. ints DataObject custNumProperty = dynamic.createDataObject (property); custNumProperty.set(name, custNum); custNumProperty.set(type, intType); custNumProperty.set(many, true); However i am unable set values to the data object once i do this.I get the following stack trace when i do this, DataObject createdDO = DataFactory.INSTANCE.create( http://www.dynamic.com/dynamic;, DataType); createdDO.setInt(custNum, 1000); java.lang.ClassCastException: java.lang.Integer at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicSet( EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet( BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet( DynamicDataObjectImpl.java :150) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java :1442) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set (DataObjectImpl.java :143) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java :532) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java :526) (if i leave out the many true flag, then the xsd displays them as attributes and i am able to set values to them) My code is attached for your review. I would appreciate your help in this regard. The reason i want to dynamically define the type is because my client requires high performant code. The time taken to execute the dynamic xsd is quite less compared to the time taken to read the xsd. Almost a whole second. Thanks and regards Roshan The samples provide an example where the dynamically defined types result in attributes and not elements. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dynamic Type Definition...
Hi All, Tuscany SDO version: Tuscany SDO 1.0 beta1. I'm trying to dynamically create and use types without the use of an XSD file. What i want to do is something a little different to what is described in the samples provided. I want to have elements within each nested type. i also want to to be able to support lists (String lists, Interger lists etc). My dynamically defined XSD should look like this (complete xsd is attached...), xsd:element name=dataType type=DataType/ xsd:complexType name=DataType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=item type=ItemType/ xsd:element maxOccurs=unbounded minOccurs=0 name=list type=ListItemType/ /xsd:sequence /xsd:complexType xsd:complexType name=ItemType xsd:sequence xsd:element name=type type=xsd:string/ xsd:element name=name type=xsd:string/ xsd:element name=boolean type=xsd:boolean/ /xsd:sequence xsd:complexType name=ListItemType xsd:sequence xsd:element name=listType type=xsd:string/ xsd:element name=listName type=xsd:string/ xsd:element name=booleanList type=BooleanListType/ /xsd:sequence /xsd:complexType xsd:complexType name=BooleanListType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name= booleanValue type=xsd:boolean/ /xsd:sequence /xsd:complexType I added the many true option when creating the property for each data object which resulted in type, name and boolean resulting in elements. // create data graph root DataGraph dataGraph = SDOUtil.createDataGraph(); DataObject dynamic = dataGraph.createRootObject(commonj.sdo, Type); dynamic.set(uri, http://www.dynamic.com/dynamic;); dynamic.set(name, DataType); dynamic.set(dataType, false); // primitive type.. ints DataObject custNumProperty = dynamic.createDataObject(property); custNumProperty.set(name, custNum); custNumProperty.set(type, intType); custNumProperty.set(many, true); However i am unable set values to the data object once i do this.I get the following stack trace when i do this, DataObject createdDO = DataFactory.INSTANCE.create( http://www.dynamic.com/dynamic;, DataType); createdDO.setInt(custNum, 1000); java.lang.ClassCastException: java.lang.Integer at org.eclipse.emf.ecore.util.EcoreEList.set(EcoreEList.java:448) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicSet (EStructuralFeatureImpl.java:1647) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet( BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet( DynamicDataObjectImpl.java:150) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java :1442) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet( BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java :143) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java :532) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java :526) (if i leave out the many true flag, then the xsd displays them as attributes and i am able to set values to them) My code is attached for your review. I would appreciate your help in this regard. The reason i want to dynamically define the type is because my client requires high performant code. The time taken to execute the dynamic xsd is quite less compared to the time taken to read the xsd. Almost a whole second. Thanks and regards Roshan The samples provide an example where the dynamically defined types result in attributes and not elements. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
