Re: Rules for determining binding endpoint URIs, was: Binding endpoints (was Fwd: Services and WSDL files
On 8/1/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: [snip] Another problem is all our bindings work differently. So binding.ws/, binding.rmi/ binding.jms/ binding.jsonrpc/ etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri=foo for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this? I think that these URIs should be determined as part of the process of combining wires and uris specified at different levels in the SCA assembly. If the correct URIs are determined once as part of this process, a binding provider should be able to just call binding.getURI(), without having to calculate it at all, on its own or even calling a central URI calculator method. Before trying to implement a common algorithm for all bindings, I thought I'd double check the various SCA spec docs. Here's what I found: - WebService binding absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri or absolute URI specified in WSDL or base domain URI for http: + '/' + component URI + '/' + relative URI specified in WSDL or absolute URI specified in a wsa:Address or base domain URI for http: + '/' + component URI + '/' + relative URI specified in a wsa:Address - JMS binding JMS specific URI specified in binding/@uri or no URI, combination of JMS specific attributes - EJB binding base domain URI for corba:iiop: + '#' + relative URI specified in binding/@uri or base domain URI for corba:rir: + '#' + relative URI specified in binding/@uri or absolute URI specified in binding/@uri I think that other bindings introduced by Tuscany can follow similar patterns: - RMI binding similar to EJB binding - JSON, Ajax and Feed bindings absolute URI specified in binding/@uri or base domain URI for http: + '/' + component URI + '/' + relative URI specified in binding/@uri Thoughts? could you guys please review to make sure I understood the specs correctly? Thanks. After more reading of the various SCA specs, I think we should defer supporting a domain URI (or a set of domain URIs) until the specs clarify the use cases for it. Here are the issues I'm seeing: - Component URI is not clearly defined in the spec (there's an errata for this), the name of the component cannot be used alone for nested components, and concatenating names of nested components with a domain URI is likely to cause ambiguities and collisions. - Having a domain URI per node in a domain (proposed earlier in this thread) is not in line with the spec. - Also doing that will burn the node topology in the SCA domain logical assembly, as you'll see the addresses of your nodes in the URIs on your reference bindings, so the logical assembly won't be so logical anymore :) - We could say that the domain URI is just a logical URI, but then I don't understand why we would need it at all, as specifying domainURI/someURI in the URI of a reference binding would only compete with the target attribute of a reference or wire. - And if it was just a logical URI then I'm not sure why we'd need a different URI per protocol. So at this point I don't understand how this domain URI was intended to be used and I think we should keep things simple. I'd suggest to not try to use a domain URI to calculate any binding URIs for now, and ask application developers and assemblers to specify the URIs they want explicitly. If anyone out there has a requirement for domain URIs and can articulate the use case and how it should work, please shout :) Finally, the SCA assembly model is already able to store a single URI in the domain's Composite model object (see Composite.get/setURI()), so if people find a real use case and are OK to start with a single domain URI, they can just use that. Thoughts? So what is the proposal exactly - ask application developers and assemblers to specify the URIs they want explicitly - could there be some examples of what that would mean for our various http based bindings? ...ant
Re: Support for SCA Java package imports/exports, was: svn commit: r559257
On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 31, 2007 3:29 AM Subject: Re: Support for SCA Java package imports/exports, was: svn commit: r559257 On 7/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Luciano Resende wrote: - Another issue I noticed is regarding resolving classReferences. Because loading a given class would never fails (no class loader isolation) there is never going to be delegation to the proper modelResolver from a contribution that is exporting the package. Any ideas here ? Or should we revisit this when we enhance classLoader support? Right, SCA Java imports will only be effective in environments using a different classloader per SCA contribution, which we have not encountered yet. I'd suggest to revisit this when we encounter such an environment. For now adding support for Java import/export only helps validate the import/export extensibility mechanism. How about we create such an environment? We seemed to be getting lots of new function added these days - for things like starting and stopping, incremental updates, this import/export stuff, etc - but nothing that actually properly uses the function, and then issues like the above mentioned class loader problem meaning its actually not at all easy to use the function when you do try to. I don't think thats so good for the project as it makes it hard to understand why things a getting so complicated, so wouldn't it be better to have something 'real' that exercises that code? How about we create an environment that properly demonstrates using multiple contributions and all the code and function we're adding around that? I think we need to have a good balance here. Writing a new Tuscany server is exciting. For those who already run their applications on existing host environment such as Tomcat and Geronimo, maybe it's more desirable to have Tuscany to be well integrated/embedded. I agree with you that we need to have something real that exercises the new features. IMHO, Tuscany/Geronimo integration will be a good testbed. I don't know details of whats happening in Geronimo, is it getting support for all the things like incremental updates, isolated class loaders, import/export etc, and if so could more of that work happen here in Tuscany so it can be shared by other things like Tomcat integration / webapps / what-ever-else that comes along? I think its important to have this here in Tuscany so will try to continue working on things like the webapp distribution, seems a shame to be duplicating work thats going on elsewhere. ...ant
Re: SDO Static Type introspection on web apps, was : Re: svn commit: r561293 - /incubator/tuscany/java/sca/modules/databinding-sdo/src/main/java/org/apache/tuscany/sca/databinding/sdo/ImportSDOPostPro
On 8/1/07, Luciano Resende [EMAIL PROTECTED] wrote: snip BTW, one way or another, I still get an exception on the JSP, did you see that ? Probably as the wsdl endpoint was set for the Jetty host not a webapp environment (...see all the threads about endpoints dancing about:)). As the testcase isn't actually testing it in Jetty I've changed the wsdl to match the webapp endpoint. Works fine for me now. ...ant
Re: [DAS] DAS SDO
ASo far, RDB DAS was doing SDOUtil.createTypeHelper() during each construction of GraphBuilderMetadata(GBMD). This was resulting in a new instance fo TypeHelper for each new query execution. This is not required as the data model used during one runtime of DAS is constant. BUsing the new SDO APIs, we can do HelperProvider.getDefaultContext ().getTypeHelper() in this case to consistently use the same TypeHelper instance. CAnother question is, when a user extends ReadCommandImpl and also provide a static data model - like in - ReadCustomersStaticTypesCommand from test suite, and also uses a HelperContext different than DefaultContext to register the static Types, (please see, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20743.html), then how to make DAS and thus GraphBuiilderMetaData aware of this new HelperContext. One simple solution will be providing a way through DASImpl to pass the helperContext to GraphBuilderMetaData, when it is not the DefaultContext. BaseCommandImpl, can hold ref to HelperContext instance and pass it to GBMD. GBMD will use passed HelperContext and in its absense will use the default one. D Alternative to C will be mandating user to use DefaultHelperContext? Please give comments. Regards, Amita On 7/20/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I have started checking the details and will consolidate my findings here. Regards, Amita On 7/20/07, Luciano Resende [EMAIL PROTECTED] wrote: Hey Kelvin gave as some head's up of upcoming changes that might affect DAS [1] and [2] (Thanks Kelvin). I think there is also a JIRA regarding integration with latest SDO 2.1 APIs [2] and the usage of deprecated SDO APIs [4]. It would be great if someone could help on getting these issues and JIRAs reviewed, and submit patches as needed. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20388.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20369.html [3] http://issues.apache.org/jira/browse/TUSCANY-986 [4] http://issues.apache.org/jira/browse/TUSCANY-961 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1501) Cannot expose services using multiple http ports
Cannot expose services using multiple http ports Key: TUSCANY-1501 URL: https://issues.apache.org/jira/browse/TUSCANY-1501 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Fix For: Java-SCA-Next The Tomcat and Jetty servlet hosts both have a limitation that only one port number can be used to listen for servlet requests. For absolute URIs specified explictly in SCDL or WSDL, this means that the same port number must be specified for all endpoints. For relative URIs such as the implicit URIs created for Web Service callback endpoints, this means that all explicitly specified absolute URIs must have port numbers that match the default port number that is hard-wired into the Web Service binding (currently 8085). The problem is easily illustrated by running the simple-callback-ws sample. This sample specifies an explicit absolute URI in the WSDL using a port number of 8085 which matches the default base URI in Axis2ServiceProvider. The sample runs because the implicit and explicit port numbers match. If the explicit port number in the WSDL for the MyService service is changed to 8075 (or any other value), the sample no longer runs because the service method is not dispatched by the servlet host. -- 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]
Missing emails for tuscany-dev posts
From time to time I come across posts to the tuscany-dev list that I did not receive by email. Normally these are present in the archive, though on the latest occasion (the first two quoted messages within [1]) the archive does not have them either. This may be a different issue from the one that I am used to seeing. I notice this about once every couple of weeks or so. I don't know how many other posts to the list I may have missed that I did not notice. Has anyone else seen this problem? I am not sure if the messages are getting dropped at the Apache end or by my mail server. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20556.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1397) createDataObject() throws NPE if property does not exist
[ https://issues.apache.org/jira/browse/TUSCANY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516978 ] Caroline Maynard commented on TUSCANY-1397: --- The current SDO C++ implementation does create the property on demand, and does not throw an exception. The PHP SDO implementation makes use of this behaviour. Of course it would be a SMOP to change the PHP code to use an alternative mechanism ... but what alternative mechanism exists in the spec? createDataObject() throws NPE if property does not exist Key: TUSCANY-1397 URL: https://issues.apache.org/jira/browse/TUSCANY-1397 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Andy Grove Calling createDataObject( foo ) where the data object's type does not define a property foo causes a null pointer exception in DataObjectUtil.createDataObject(DataObject dataObject, Property property, Type type) because it attempts to call property.isContainment without checking if the property is null. Calling createDataObject( foo ) on an open type should create an on-demand property. If the type is not open and the property does not exist then an exception should be thrown. Thanks, Andy. -- 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: 39 unscheduled JIRAs, 3 with no component, 24 with patches
Is anyone able to look at the patch for TUSCANY-1356 that I posted some time ago? There was a bit of discussion (see [1]) but it didn't reach a conclusion. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html Jean-Sebastien Delfino wrote: We have 39 unscheduled JIRAs, see: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210fixfor=-1resolution=-1sorter/field=prioritysorter/order=DESC 3 JIRAs with no component: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210component=-1resolution=-1sorter/field=prioritysorter/order=DESC 24 outstanding patches!! https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210resolution=-1customfield_12310041=Patch+Availablesorter/field=updatedsorter/order=DESC Any chance that the reporters or assignees take a few minutes at these JIRAs to: - schedule them - assign them to the correct component - mark the JIRAs with patches which have been resolved... resolved? I'll start with mine... hoping to see others help as well. I think it'll help us see more clear through our JIRA backlog. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Build Issues with SCA 0.91 and later
Hey Tuscany gurus, I've been (unsuccessfully) trying to get the SCA source code to build for the last day or two using Maven. While I eventually got the 0.91 baseline to build, I've had no real progress on the HEAD code. The most common problem when building either the baseline or Head (using mvn or 'mvn -U -cpu') is missing artifacts, although since the absent resource is often a Tuscany file, I've been able to fix some of the issues by just running mvn in the required directory. That only gets me so far with the HEAD, since I either end up trying to build a resource that's missing other dependencies I can't get to build or I get a ClassNotFoundException. For example, my most recent error stated I was missing this artifact: org.apache.tuscany.sca:tuscany-itest-contribution-import-export-contrib-composite:jar:1.0-incubating-SNAPSHOT I tried running maven in Tuscany\java\sca\itest\contribution-import-export but got this error: ... Running helloworld.HelloWorldServerTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.688 sec FAILURE! testPing(helloworld.HelloWorldServerTestCase) Time elapsed: 2.578 sec ERROR! org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl Other files I've had to build manually include: -org.apache.tuscany.sca:tuscany-interface-java:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT - org.apache.tuscany.sca:tuscany-implementation-notification:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:tuscany-topology:jar:1.0-incubating-SNAPSHOT and a few others... None were available when I navigated to their location using my browser. The POM files all seem to roughly match the directory structure (any missing or commented modules in the POM file are not the ones causing problems in the build) and I've tried clean builds repeatedly (cleaning my local repository and the target directories) with no luck. My setup: -Intel Core 2/2 GB Ram/Win XP -Maven 2.0.7 (although I've also tried 2.0.6) -Java SE 5 (JDK 5.0_12) since Java SE 6 was causing javax problems: Running crud.CRUDTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.625 sec FAILURE! testCRUD(crud.CRUDTestCase) Time elapsed: 0.578 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java :158) ... -going through a web proxy configured as below: (although I've tried direct and not resolved any issues.) proxies proxy activetrue/active protocolhttp/protocol hostgateway.xxx/host port8000/port nonProxyHosts10.*.*.*|172.*.*.*|192.*.*.*|*.xxx|sysgroupsps1|localhost|127.0.0.1/nonProxyHosts /proxy /proxies Any suggestions as to how I can find the missing artifacts (perhaps a better repository?) are greatly appreciated! Thanks for your help, -Mike
[jira] Assigned: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-1347: --- Assignee: Simon Nash (was: Luciano Resende) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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: LocateService API Issues and JIRAs
Comment inline. Simon Jean-Sebastien Delfino wrote: Luciano Resende wrote: I noticed some JIRAS around the locateService API and I will spend some time to investigate these issues. So far, I have found TUSCANY-1347 [1] and TUSCANY-1328 [2] : TUSCANY-1347 current status is resolved/cannot reproduce, but I looking at the attached test case and patch, it looks like it wasn't applied. By reading the JIRA, looks like the original issue reported was that an IndexOutOfBoundsException exception was being thrown instead of org.osoa.sca.ServiceRuntimeException: Service not found exception. I'm the one who marked 1347 cannot reproduce, as I couldn't understand from the JIRA what the issue was about, and therefore what the patch was supposed to fix :) I asked the reporters of the JIRA issue to please provide a clear description of the issue. It's nice of you to reopen it for investigation, but the initial reporters need to step in and provide more information. Also when I ran the test case on the trunk I got a completely different error, see the stack trace I added to the JIRA. This line 41 NPE stack trace is familiar to me from my recent work on the default SCA binding. I have assigned this JIRA to myself to investigate further. The test is probably exposing a corner case that was not covered correctly in the recent default SCA binding work. TUSCANY-1328 is about not being able to locate service from a component whose implementation is composite. Please let me know if I have the correct understanding of the issue described in TUSCANY-1347 as it comments are a little unclear, and also let me know if anyone knows about other issues on this area, so I could try to address them all together. [1] https://issues.apache.org/jira/browse/TUSCANY-1347 [2] https://issues.apache.org/jira/browse/TUSCANY-1328 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website ACL
My CLA is in place and recorded on [1]. Please give me write access. Simon [1] http://people.apache.org/~jim/committers.html Amita Vadhavkar wrote: I'd like write access please. I have a CLA in place. Thank you. Amita On 7/18/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Thank you, Ant. On 7/18/07, ant elder [EMAIL PROTECTED] wrote: This is now in place and changes to the Tuscany cwiki now have emails sent to tuscany-commits ...ant On 7/17/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Ant, Please drop an email to apmail AT apache.org. thanks, dims On 7/16/07, ant elder [EMAIL PROTECTED] wrote: On 7/15/07, ant elder [EMAIL PROTECTED] wrote: snip If we could get cwiki change emails sent to the tuscany-commit mailing list so its easy to give some oversight then I'd be in favour of a very low bar of entry. I had a try at doing this by setting up a cwiki user using the [EMAIL PROTECTED] email address and adding that user as a watcher of the cwiki space. This works but all the emails from [EMAIL PROTECTED] to the tuscany-commits list require moderation which is a bit of a pain. Does any one know of a way around this? We need some way to allow [EMAIL PROTECTED] to post to the tuscany-commits list without having to subscribe it to the list so we don't send all the commit emails to [EMAIL PROTECTED] (CC'ing you dims as you seem to have lots of mailing lits powers so may know some way around this?) ...ant -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
If I understand this comment correctly, this is a spec violation that needs to be fixed. From the assembly 1.0 spec: 2535 schemas. New interface types, implementation types and binding types that are defined using 2536 this extensibility model, which are not part of these SCA specifications must be defined in 2537 namespaces other than the SCA namespace. Simon ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Build Issues with SCA 0.91 and later
Hi Mike This is a MAVEN issue, and we are trying to get help from the maven developers [1]. In the meantime, a workaround we found was to publish snapshots of all artifacts, the ones you mentioned, for itest/contribution-import-export were renamed recently, let me publish new snapshots in one hour or so, I'll let you know when they are published. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20844.html On 8/1/07, Mike Spendlove [EMAIL PROTECTED] wrote: Hey Tuscany gurus, I've been (unsuccessfully) trying to get the SCA source code to build for the last day or two using Maven. While I eventually got the 0.91 baseline to build, I've had no real progress on the HEAD code. The most common problem when building either the baseline or Head (using mvn or 'mvn -U -cpu') is missing artifacts, although since the absent resource is often a Tuscany file, I've been able to fix some of the issues by just running mvn in the required directory. That only gets me so far with the HEAD, since I either end up trying to build a resource that's missing other dependencies I can't get to build or I get a ClassNotFoundException. For example, my most recent error stated I was missing this artifact: org.apache.tuscany.sca:tuscany-itest-contribution-import-export-contrib-composite:jar:1.0-incubating-SNAPSHOT I tried running maven in Tuscany\java\sca\itest\contribution-import-export but got this error: ... Running helloworld.HelloWorldServerTestCase Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 2.688 sec FAILURE! testPing(helloworld.HelloWorldServerTestCase) Time elapsed: 2.578 sec ERROR! org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.lang.ClassNotFoundException: helloworld.HelloWorldImpl Other files I've had to build manually include: -org.apache.tuscany.sca:tuscany-interface-java:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:sample-helloworld-dojo:war:1.0-incubating-SNAPSHOT - org.apache.tuscany.sca:tuscany-implementation-notification:jar:1.0-incubating-SNAPSHOT -org.apache.tuscany.sca:tuscany-topology:jar:1.0-incubating-SNAPSHOT and a few others... None were available when I navigated to their location using my browser. The POM files all seem to roughly match the directory structure (any missing or commented modules in the POM file are not the ones causing problems in the build) and I've tried clean builds repeatedly (cleaning my local repository and the target directories) with no luck. My setup: -Intel Core 2/2 GB Ram/Win XP -Maven 2.0.7 (although I've also tried 2.0.6) -Java SE 5 (JDK 5.0_12) since Java SE 6 was causing javax problems: Running crud.CRUDTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.625 sec FAILURE! testCRUD(crud.CRUDTestCase) Time elapsed: 0.578 sec ERROR! javax.xml.stream.FactoryConfigurationError: Provider javax.xml.stream.XMLInputFactory could not be instantiated: java.lang.InstantiationException at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java :158) ... -going through a web proxy configured as below: (although I've tried direct and not resolved any issues.) proxies proxy activetrue/active protocolhttp/protocol hostgateway.xxx/host port8000/port nonProxyHosts10.*.*.*|172.*.*.*|192.*.*.*|*.xxx|sysgroupsps1|localhost|127.0.0.1/nonProxyHosts /proxy /proxies Any suggestions as to how I can find the missing artifacts (perhaps a better repository?) are greatly appreciated! Thanks for your help, -Mike -- 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: [Spec Related] 'provides' attribute in PolicySet
Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and policyset defined in a specific definitions.xml is the value of the 'targetNamespace' attribute of the 'definitions' element. Is this right? - Can a qualified intent have its qualifiable parent intent belonging to a different targetnamespace. If so how would this be evident from the name of the qualified intent? For example if there is an intent a:intentOne and then there is a qualified intent over this like intentOne.intentTwo - how is to be inferred that intentOne belongs to a different namespace Thanks - Venkat On 7/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, AFAIK, policySet can be used directly without going through intents. So a policySet is still valid even it doesn't provide any intents. Please see the SCA Policy Framework Spec V1.0 starting from line 529: 529 Similarly, one or more policySets can be attached to any SCA element used in the definition of 530 components and composites. The attachment is specified by using the optional @policySets 531 attribute. This attribute takes as its value a list of policySet names. 532 For example, 533 534 service or reference. 535 binding.binding-type policySets=listOfQNames 536 /binding.binding-type. 537 /service or /reference ... Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, July 31, 2007 7:24 AM Subject: [Spec Related] 'provides' attribute in PolicySet Hi, In the specs for the PolicyFwk, the xsds mention the 'provides' attribute for a 'policySet' as optional. If this attribute is not specified how does one figure out which intent a particular policySet actually provides for. Could somebody help me with clarity on this, please? Thanks - Venkat - 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] Resolved: (TUSCANY-1501) Cannot expose services using multiple http ports
[ https://issues.apache.org/jira/browse/TUSCANY-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-1501. - Resolution: Fixed Fixed in revision 561391 Cannot expose services using multiple http ports Key: TUSCANY-1501 URL: https://issues.apache.org/jira/browse/TUSCANY-1501 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Fix For: Java-SCA-Next The Tomcat and Jetty servlet hosts both have a limitation that only one port number can be used to listen for servlet requests. For absolute URIs specified explictly in SCDL or WSDL, this means that the same port number must be specified for all endpoints. For relative URIs such as the implicit URIs created for Web Service callback endpoints, this means that all explicitly specified absolute URIs must have port numbers that match the default port number that is hard-wired into the Web Service binding (currently 8085). The problem is easily illustrated by running the simple-callback-ws sample. This sample specifies an explicit absolute URI in the WSDL using a port number of 8085 which matches the default base URI in Axis2ServiceProvider. The sample runs because the implicit and explicit port numbers match. If the explicit port number in the WSDL for the MyService service is changed to 8075 (or any other value), the sample no longer runs because the service method is not dispatched by the servlet host. -- 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] Closed: (TUSCANY-1501) Cannot expose services using multiple http ports
[ https://issues.apache.org/jira/browse/TUSCANY-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash closed TUSCANY-1501. --- Cannot expose services using multiple http ports Key: TUSCANY-1501 URL: https://issues.apache.org/jira/browse/TUSCANY-1501 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Fix For: Java-SCA-Next The Tomcat and Jetty servlet hosts both have a limitation that only one port number can be used to listen for servlet requests. For absolute URIs specified explictly in SCDL or WSDL, this means that the same port number must be specified for all endpoints. For relative URIs such as the implicit URIs created for Web Service callback endpoints, this means that all explicitly specified absolute URIs must have port numbers that match the default port number that is hard-wired into the Web Service binding (currently 8085). The problem is easily illustrated by running the simple-callback-ws sample. This sample specifies an explicit absolute URI in the WSDL using a port number of 8085 which matches the default base URI in Axis2ServiceProvider. The sample runs because the implicit and explicit port numbers match. If the explicit port number in the WSDL for the MyService service is changed to 8075 (or any other value), the sample no longer runs because the service method is not dispatched by the servlet host. -- 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: Maven tries to resolve artifact in the reactor to SNAPSHOT version in Apache Tuscany build
Just trying to give some updates here... looks like this recent build issues we are having might be a side effect of the fix for Maven JIRA MNG-1577 [1], some more details are available here [2] and [3]. While we investigate the issue further, a possible workaround (that worked for me) is to move back to maven 2.0.5 client [4]. Please let me know if this works for you as a temporary workaround. And many thanks to brett_ and others for helping on IRC. [1] http://jira.codehaus.org/browse/MNG-1577 [2] http://maven.apache.org/release-notes.html [3] http://maven.apache.org/plugins/maven-dependency-plugin/examples/preparing-dependencies.html [4] http://archive.apache.org/dist/maven/binaries/maven-2.0.5-bin.zip On 7/27/07, Luciano Resende [EMAIL PROTECTED] wrote: Hi Guys We are experiencing some issues in Apache Tuscany build recently as described on this thread [1]. Basically, anyone starting with a clean local maven repo are seeing the artifacts that are supposed to be built in the reactor, to be resolved to a published SNAPSHOT version, and thus, the build is failing if any of the problematic artifacts doesn't have a published snapshot. This only started recently, around July 24th or 25th, and looks like people that have an old maven repository can build things OK. Could someone please give us some help, or guidance on how to investigate the issue. If you need any other information, please let us know, and our source code is available at [2] and we are trying to build [3]. BTW, could you please post a response to both lists. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20739.html [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/ [3] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ -- 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]
[jira] Created: (TUSCANY-1502) @OneWay annotation not working with default SCA binding
@OneWay annotation not working with default SCA binding --- Key: TUSCANY-1502 URL: https://issues.apache.org/jira/browse/TUSCANY-1502 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next The @OneWay annotation has no effect when used with the default SCA binding. -- 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-1503) Add test case for callback with multiple wires
Add test case for callback with multiple wires -- Key: TUSCANY-1503 URL: https://issues.apache.org/jira/browse/TUSCANY-1503 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Add test case for callback service with multiple wires pointing to it, to show that callbacks are directed correctly according to which inbound wire was used for the forward call. -- 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-1503) Add test case for callback with multiple wires
[ https://issues.apache.org/jira/browse/TUSCANY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1503: Attachment: callback-multiple-wires.zip Test case attached. Add test case for callback with multiple wires -- Key: TUSCANY-1503 URL: https://issues.apache.org/jira/browse/TUSCANY-1503 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: callback-multiple-wires.zip Add test case for callback service with multiple wires pointing to it, to show that callbacks are directed correctly according to which inbound wire was used for the forward call. -- 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-1498) Improve SubstitutionValuesTestCase
[ https://issues.apache.org/jira/browse/TUSCANY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Gavlin updated TUSCANY-1498: Patch Info: [Patch Available] Improve SubstitutionValuesTestCase -- Key: TUSCANY-1498 URL: https://issues.apache.org/jira/browse/TUSCANY-1498 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Ron Gavlin Priority: Minor Attachments: tuscany-sdo-impl.TUSCANY-1498.patch Improve SubstitutionValuesTestCase. Will attach a patch in the near future. -- 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-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517080 ] Luciano Resende commented on TUSCANY-1347: -- Although I can't reproduce the error, I have added some new test to exercise the behavior described on this JIRA under revision #561957 (under /java/sca/itest/recursive) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- 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-1484) StackOverflowException invoking isSet on a static DataObject with a dynamically-added property
[
https://issues.apache.org/jira/browse/TUSCANY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Gavlin updated TUSCANY-1484:
Attachment: tuscany-sdo.TUSCANY-1484.patch
This patch includes an add'l test in tools/.../ExtensibleTestCase that exposes
the bug. It also includes modifications to impl classes to fix the bug.
StackOverflowException invoking isSet on a static DataObject with a
dynamically-added property
--
Key: TUSCANY-1484
URL: https://issues.apache.org/jira/browse/TUSCANY-1484
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Attachments: tuscany-sdo.TUSCANY-1484.patch
I have a Type and a corresponding statically-generated class. At runtime, I
dynamically add an add'l Property to this Type using
SDOUtil.createProperty(). Then, when I invoke
dataObjectInstance.isSet(dynamicallyAddedProperty), the
StackOverflowException listed below is generated:
java.lang.StackOverflowError
at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
at org.apache.tuscany.sdo.impl.DataObjectBase.
eStaticClass(DataObjectBase.java:378)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eClass(ExtensibleDataObjectImpl.java:118)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:815)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
Frank's characterization of the problem is included below.
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 26, 2007 3:03:15 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Since the properties start at 0, the extra property number should be equal
to INTERNAL_PROPERTY_COUNT. That looks right.
The StackOverflowException problem looks to me to be caused by the fact
that the generated methods like isSet(int) are expected to find the
property and only call super in the dynamic case. In your case, the
property isn't statically handled, so it eventually calls
DataObjectBase.eIsSet():
public boolean eIsSet(int featureID)
{
if (isDynamic())
{
return super.eIsSet(internalConvertIndex(featureID));
} else
{
return isSet(internalConvertIndex(featureID));
}
}
which will recursively call isSet() again because isDynamic() returns
false. Somehow the code needs to be changed so that the dynamic property
also causes it to go down the isDynamic() path.
Actually, this eIsSet() method looks fishy to me regardless. First, the
call to internalConvertIndex(featureID) for the call to super.eIsSet()
looks wrong to me. I think it should be just featureID. The super call is
expecting the internal (EMF) number, not the converted SDO number. Second,
even in the dynamic sublass case (which this is supposed to be handling, I
think that a client call to eIsSet() won't work, because it won't ever go
down the isSet() patch which handles the static properties (in the base
class(es)).
I think the isDynamic() part of this method should be removed and instead
there should be an implementation of isSet(int) (in ExtensibleDataObject
probably?) that handles the case of a property that is either in a dynamic
sublass or was dynamically added to a static type.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
Frank,
This scenario appears to trigger a property-indexing problem. The
newly added property's EMF featureID of 18 equals the value of
MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
[jira] Resolved: (TUSCANY-1503) Add test case for callback with multiple wires
[ https://issues.apache.org/jira/browse/TUSCANY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1503. --- Resolution: Fixed Patch applied under r561962. Thank you, Simon. Add test case for callback with multiple wires -- Key: TUSCANY-1503 URL: https://issues.apache.org/jira/browse/TUSCANY-1503 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: callback-multiple-wires.zip Add test case for callback service with multiple wires pointing to it, to show that callbacks are directed correctly according to which inbound wire was used for the forward call. -- 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-1484) StackOverflowException invoking isSet on a static DataObject with a dynamically-added property
[
https://issues.apache.org/jira/browse/TUSCANY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Gavlin updated TUSCANY-1484:
Patch Info: [Patch Available]
StackOverflowException invoking isSet on a static DataObject with a
dynamically-added property
--
Key: TUSCANY-1484
URL: https://issues.apache.org/jira/browse/TUSCANY-1484
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Attachments: tuscany-sdo.TUSCANY-1484.patch
I have a Type and a corresponding statically-generated class. At runtime, I
dynamically add an add'l Property to this Type using
SDOUtil.createProperty(). Then, when I invoke
dataObjectInstance.isSet(dynamicallyAddedProperty), the
StackOverflowException listed below is generated:
java.lang.StackOverflowError
at mypackage.impl.MyFactoryImpl.getMyType(MyFactoryImpl.java:1135)
at mypackage.impl.MyTypeImpl.getStaticType(MyTypeImpl.java:821)
at org.apache.tuscany.sdo.impl.DataObjectBase.
eStaticClass(DataObjectBase.java:378)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eClass(ExtensibleDataObjectImpl.java:118)
at org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.
eDerivedStructuralFeatureID(ExtensibleDataObjectImlp.java:87)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:815)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
at mypackage.sdo.impl.MyTypeImpl.setSet(MyTypeImpl.java:2005)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eIsSet(DataObjectBase.java:437)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.
eIsSet(BasicEObjectimpl.java:818)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DataObjectImpl.java:152)
at
org.apache.tuscany.sdo.impl.DataObjectImpl.isSet(DatObjectImpl.java:112)
...
Frank's characterization of the problem is included below.
- Original Message
From: Frank Budinsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 26, 2007 3:03:15 PM
Subject: Re: How to add Property to an XSDHelper-defined Type
Since the properties start at 0, the extra property number should be equal
to INTERNAL_PROPERTY_COUNT. That looks right.
The StackOverflowException problem looks to me to be caused by the fact
that the generated methods like isSet(int) are expected to find the
property and only call super in the dynamic case. In your case, the
property isn't statically handled, so it eventually calls
DataObjectBase.eIsSet():
public boolean eIsSet(int featureID)
{
if (isDynamic())
{
return super.eIsSet(internalConvertIndex(featureID));
} else
{
return isSet(internalConvertIndex(featureID));
}
}
which will recursively call isSet() again because isDynamic() returns
false. Somehow the code needs to be changed so that the dynamic property
also causes it to go down the isDynamic() path.
Actually, this eIsSet() method looks fishy to me regardless. First, the
call to internalConvertIndex(featureID) for the call to super.eIsSet()
looks wrong to me. I think it should be just featureID. The super call is
expecting the internal (EMF) number, not the converted SDO number. Second,
even in the dynamic sublass case (which this is supposed to be handling, I
think that a client call to eIsSet() won't work, because it won't ever go
down the isSet() patch which handles the static properties (in the base
class(es)).
I think the isDynamic() part of this method should be removed and instead
there should be an implementation of isSet(int) (in ExtensibleDataObject
probably?) that handles the case of a property that is either in a dynamic
sublass or was dynamically added to a static type.
Frank.
Ron Gavlin [EMAIL PROTECTED] wrote on 07/26/2007 01:09:27 PM:
Frank,
This scenario appears to trigger a property-indexing problem. The
newly added property's EMF featureID of 18 equals the value of
MyTypeImpl.SDO_PROPERTY_COUNT and MyTypeImpl.
INTERNAL_PROPERTY_COUNT. This appears to cause an infinite loop. Any
ideas for working around this problem?
- Ron
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
[jira] Updated: (TUSCANY-1502) @OneWay annotation not working with default SCA binding
[ https://issues.apache.org/jira/browse/TUSCANY-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1502: Attachment: patch1502 The value returned from supportsAsyncOneWayInvocation() by RuntimeSCAReferenceBindingProvider and RuntimeSCAServiceBindingProvider was true. These methods should both return false. @OneWay annotation not working with default SCA binding --- Key: TUSCANY-1502 URL: https://issues.apache.org/jira/browse/TUSCANY-1502 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1502 The @OneWay annotation has no effect when used with the default SCA binding. -- 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-1464) Wrong query results when SELECT misses PKs
[ https://issues.apache.org/jira/browse/TUSCANY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517084 ] Adriano Crestani commented on TUSCANY-1464: --- reviewing patch ; ) Adriano Crestani Wrong query results when SELECT misses PKs -- Key: TUSCANY-1464 URL: https://issues.apache.org/jira/browse/TUSCANY-1464 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1464.patch http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20322.html Fix the bug uncovered in above mail discussion. -- 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]
Fwd: August Reports
It's that time again for us, I have started a draft report on our wiki [1], let's get it updated asap. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Incubation+Board+Reports+-+August+2007 -- Forwarded message -- From: Noel J. Bergman [EMAIL PROTECTED] Date: Aug 1, 2007 7:52 PM Subject: August Reports To: [EMAIL PROTECTED] Just getting the reminder in early --- those projects reporting in August, please start working on and posting your reports. --- Noel - 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] Assigned: (TUSCANY-1495) LDAP DAS Contribution
[ https://issues.apache.org/jira/browse/TUSCANY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1495: Assignee: Luciano Resende LDAP DAS Contribution - Key: TUSCANY-1495 URL: https://issues.apache.org/jira/browse/TUSCANY-1495 Project: Tuscany Issue Type: New Feature Components: Java DAS LDAP Affects Versions: Java-DAS-Next Reporter: Ole Ersoy Assignee: Luciano Resende Priority: Minor Fix For: Java-DAS-Next Attachments: das.ldap.parent.zip Hi, The attached zip contains the LDAP DAS Contribution. The current implementation uses EMF (EDataGraph, EDataObject/EObject, EClass), but the plan is to make the LDAP DAS implementation independent. In order to compile and run the tests, the lastest snapshot of ApacheDS must be installed in the maven repository. http://directory.apache.org/community%26resources/sources.html The LdapDASTest.java contains the tests that test the DAS interface. The current LdapDAS interface throws LDAP specific exceptions, but we'll figure out some elegant ways of handling these, while wrapping it in the Tuscany DAS interface . Emmanuel Lecharny, Alex Karasulu, and the rest of the Apache Directory Team have been super helpful and supportive in getting this DAS implementation done and this implementation owes a lot to their hard work on the directory server, particularly the dynamic schema capability. Also, Ed Merks (EMF) was very helpful in finding the relevant components of the EMF API. Cheers, - Ole -- 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]
