Re: JSON databinding for Tuscany
Raymond Feng wrote: Hi, I prototyped a JSON databinding for Tuscany which supports the data transformation between JSON and XML. The code is based on Jettison (http://jettison.codehaus.org/) which is used by Axis2 and CXF too. Do you see any value of this? Ant, is it going to help JSON-RPC or JavaScript? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This sounds cool, it would make things symmetric with the XML bindings we're using for WS (and which I'd like to use for REST style XML/HTTP as well as some point) but Ant can probably give a more educated view as he's been working with JSON-RPC for a while :) Would I have to go through an XML transformation if I have a JAXB or SDO object in hand and want to produce JSON? or are you going to support SDO or JAX-B to JSON directly? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Specs Related] Queries on References
[snip] Jean-Sebastien Delfino wrote: comments inline Venkata Krishnan wrote: Hi, I am trying to bring the SPI model and the Loaders in sync with the current level of the specs as available on OSOA site. I am currently looking at 'references' - as and how they are defined in ComponentType, ComponentDefinition and Composite and have the following questions: - With respect to references defined in ComponentDefitions and the 'target' attribute therein - the specs says that whatever is mentioned in the target overrides that which is mentioned in the implementation. Now, my understanding is that a target is used to wire a reference to another Component's service. Given this, I thought defining a target makes sense only within a composite. So what does it mean by an implementation specifying a target for a reference? The idea is to allow a component implementation developed with a particular composition in mind to specify a target right in the implementation. This makes the SCA programming model more compact as you may not even have to write SCDL then. SCA for PHP for example leverages this capability, here's a sample from http://us2.php.net/manual/en/ref.SCA.php: ?php /** * The currency exchange rate service to use. * * @reference * @binding.php ../ExchangeRate/ExchangeRate.php */ public $exchange_rate; ? The componentType/reference/target attribute allows you to express the same thing in a .componentType SCDL file. Then later if you want to reuse your component implementation in other compositions you can rewire the reference using a component/reference/target attribute in the particular component declaration, without changing your implementation. More generally, I've started to look more closely at the model spi as well as I'm trying to see how to reuse it as an individual module, and I'm not sure that the current ReferenceDefinition and ReferenceTarget classes correctly represent references as defined in the SCA assembly spec. The assembly spec defines the following: - abstract reference definitions in constraining types - reference definitions in component types - component references - composite references I'll try to come up with some ideas for an accurate representation of references at these 4 levels. Venkat, I've checked in a few interfaces representing the 4 kinds of References above at http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly/src/main/java/org/apache/tuscany/assembly/model/ (plus a few base interfaces to represent SCA interfaces, multiplicity, basically what I found in the SCA assembly spec for references). I think that we're going to need interfaces for the model SPI to achieve good modularization of the Kernel, so I thought I'd try to have these few interfaces actually in sync with the SCA 1.0 assembly spec. It's probably premature to try to use this assembly module as I just got it barely building today and it's not used by the rest of the runtime, but I hope that the few interfaces can help give some ideas or at least help initiate a discussion on how best to represent SCA assembly references. Let me know what you think. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Native M3 release status
Just a quick update. The doc is in order now (thanks Andy) and the distros are ok on Linux/Mac. I'm having to rework the source distro for Windows as there were some errors in the build settings. A few more minor changes to the build script to make the extensions optional and I'll be done. Cheers, -- Pete
Re: Native M3 release status
Pete Robbins wrote: Just a quick update. The doc is in order now (thanks Andy) and the distros are ok on Linux/Mac. I'm having to rework the source distro for Windows as there were some errors in the build settings. A few more minor changes to the build script to make the extensions optional and I'll be done. Cheers, Cool. I just refreshed and it built OK on Linux, except that the PHP extension was not built at all even after doing configure --enable-all-extensions. It does not seem to be built by build.sh either but I guess it's ok... I'm assuming that you're not going to include the PHP extension in the release yet? One minor thing, extensions/ws/service/deploy.sh didn't work for me, the script looks for $APFULLDIR/modules/tuscany/module.xml which does not exist. I've tested the command line and REST samples and they worked. I can help test your release candidate on Linux when it's ready. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Specs Related] Queries on References
Venkata Krishnan wrote: Hi Sebastien, I agree with your suggestions on two accounts... - its really good to have the model defined around interfaces as it gives the flexibility to improve / modify the implementations we choose over a period of time without the impacting the core which I assume will use only these interfaces. If we use factories to instantiate model objects (i.e. specific implementations of these interfaces) that will keep the core futher away from impacts of changes to implementation of the SPI model. We could probably configure the factory class to be used as part of the scdl - for example as the property of a Loader(s). Hope I am making sense? Yes, making a lot of sense to me... - Specific to the case of references, I did imagine that we may have to clearly abstract out references at componentType level, component level and composite level as there is something specific in 'references' to each level - for example the 'promote' is something that is specific to the composite level. Yes, there's a 4th level in constrainingType, which is the most abstract and does not have a binding or policySets, but I guess we can go step by step so I'm not sure we need it yet... I'll leave it up to you. I have started to make some changes in the SPI model of the kernel. But then, it is not going to be difficult for me to migrate this to your proposed design in the 'assembly'. So I shall continue for now in the kernel unless you see some issues. Good, we'll see if we have the same reading of the spec :). What I posted below was just an initial idea so let me know when you have a code update on your side and we'll see how we can exchange ideas and sync up our interfaces / classes. Thanks. - Venkat On 3/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Jean-Sebastien Delfino wrote: comments inline Venkata Krishnan wrote: Hi, I am trying to bring the SPI model and the Loaders in sync with the current level of the specs as available on OSOA site. I am currently looking at 'references' - as and how they are defined in ComponentType, ComponentDefinition and Composite and have the following questions: - With respect to references defined in ComponentDefitions and the 'target' attribute therein - the specs says that whatever is mentioned in the target overrides that which is mentioned in the implementation. Now, my understanding is that a target is used to wire a reference to another Component's service. Given this, I thought defining a target makes sense only within a composite. So what does it mean by an implementation specifying a target for a reference? The idea is to allow a component implementation developed with a particular composition in mind to specify a target right in the implementation. This makes the SCA programming model more compact as you may not even have to write SCDL then. SCA for PHP for example leverages this capability, here's a sample from http://us2.php.net/manual/en/ref.SCA.php: ?php /** * The currency exchange rate service to use. * * @reference * @binding.php ../ExchangeRate/ExchangeRate.php */ public $exchange_rate; ? The componentType/reference/target attribute allows you to express the same thing in a .componentType SCDL file. Then later if you want to reuse your component implementation in other compositions you can rewire the reference using a component/reference/target attribute in the particular component declaration, without changing your implementation. More generally, I've started to look more closely at the model spi as well as I'm trying to see how to reuse it as an individual module, and I'm not sure that the current ReferenceDefinition and ReferenceTarget classes correctly represent references as defined in the SCA assembly spec. The assembly spec defines the following: - abstract reference definitions in constraining types - reference definitions in component types - component references - composite references I'll try to come up with some ideas for an accurate representation of references at these 4 levels. Venkat, I've checked in a few interfaces representing the 4 kinds of References above at http://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/assembly/src/main/java/org/apache/tuscany/assembly/model/ (plus a few base interfaces to represent SCA interfaces, multiplicity, basically what I found in the SCA assembly spec for references). I think that we're going to need interfaces for the model SPI to achieve good modularization of the Kernel, so I thought I'd try to have these few interfaces actually in sync with the SCA 1.0 assembly spec. It's probably premature to try to use this assembly module as I just got it barely building today and it's not used by the rest of the runtime, but I hope that the few interfaces can help give some ideas or at least help initiate a discussion on how
Re: Native M3 release status
On 13/03/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Just a quick update. The doc is in order now (thanks Andy) and the distros are ok on Linux/Mac. I'm having to rework the source distro for Windows as there were some errors in the build settings. A few more minor changes to the build script to make the extensions optional and I'll be done. Cheers, Cool. I just refreshed and it built OK on Linux, except that the PHP extension was not built at all even after doing configure --enable-all-extensions. It does not seem to be built by build.sh either but I guess it's ok... I'm assuming that you're not going to include the PHP extension in the release yet? One minor thing, extensions/ws/service/deploy.sh didn't work for me, the script looks for $APFULLDIR/modules/tuscany/module.xml which does not exist. I've tested the command line and REST samples and they worked. I can help test your release candidate on Linux when it's ready. -- Jean-Sebastien PHP is not included in the main build anymore. To build it you go to sca/runtime/extensions/php and run build.sh. It has it's own autoconf/make so this does a configure/make/make install triple. It will get deployed into wherever $TUSCANY_SCACPP is set to. I'll look in to the ws deploy problem Thanks for your help. -- Pete
Re: Getting rid of TargetInvoker
On Mar 12, 2007, at 8:10 PM, Jim Marino wrote: With the connector changes and move to using only Component types for extensions, I think we can safely get rid of TargetInvoker. On Component, we will have: void attachWire(Wire wire, PhysicalWireSourceDefinition defintion); void attachWire(Wire wire, PhysicalWireTargetDefinition defintion); Scratch the addition of the interfaces as we will do this in the WireAttacher. In any event, we can still get rid of TargetInvoker. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r516600 - /incubator/tuscany/java/pom.xml
LOL, you'll need to do a bit better than that to educate us as from all the posts to this thread it doesn't seem like 'most people' understand the proposal or think it will fix the problem. How about setting up something somewhere to demonstrate what you are proposing? ...ant On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 12, 2007, at 4:05 PM, ant elder wrote: He didn't give much detail, and hasn't replied when i asked for more about what he was proposing (unless I missed the email?) Got better things to do - most people understood it which was enough for me. You might want to read up on the maven-assembly-plugin. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Intermittent hangs in SmokeTestAssemblyContent
When building the standalone module in trunk I get intermittently get an InterruptedException which causes the test to hang. I've not been able to track down whats happening yet, does anyone else get this? Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyContent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Exception in thread pool-1-thread-2 java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor( AbstractQueuedSynchronizer.java:599) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release( AbstractQueuedSynchronizer.java:1105) at java.util.concurrent.locks.ReentrantLock.unlock( ReentrantLock.java:431) at java.util.concurrent.ThreadPoolExecutor.workerDone( ThreadPoolExecutor.java:568) at java.util.concurrent.ThreadPoolExecutor$Worker.run( ThreadPoolExecutor.java:681) at java.lang.Thread.run(Thread.java:595)
Re: Intermittent hangs in SmokeTestAssemblyContent
I don't but I'm on an Intel dual core so it may be a race condition. What type of CPU are you using? Jim On Mar 13, 2007, at 3:12 AM, ant elder wrote: When building the standalone module in trunk I get intermittently get an InterruptedException which causes the test to hang. I've not been able to track down whats happening yet, does anyone else get this? Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyC ontent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Exception in thread pool-1-thread-2 java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor( AbstractQueuedSynchronizer.java:599) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release( AbstractQueuedSynchronizer.java:1105) at java.util.concurrent.locks.ReentrantLock.unlock( ReentrantLock.java:431) at java.util.concurrent.ThreadPoolExecutor.workerDone( ThreadPoolExecutor.java:568) at java.util.concurrent.ThreadPoolExecutor$Worker.run( ThreadPoolExecutor.java:681) at java.lang.Thread.run(Thread.java:595) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Intermittent hangs in SmokeTestAssemblyContent
Ant, I don't get it either, I use dual core as well. The smoke test laucher uses a process drainer on a different thread that drains the System.out and System.err, for the spawned process. I can have a look when I get home in the evening (sorry I can't access the SVN server from work). Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 10:19 AM To: tuscany-dev@ws.apache.org Subject: Re: Intermittent hangs in SmokeTestAssemblyContent I don't but I'm on an Intel dual core so it may be a race condition. What type of CPU are you using? Jim On Mar 13, 2007, at 3:12 AM, ant elder wrote: When building the standalone module in trunk I get intermittently get an InterruptedException which causes the test to hang. I've not been able to track down whats happening yet, does anyone else get this? Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestAssemblyC ontent Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.tuscany.sca.runtime.standalone.smoketest.SmokeTestLauncher Exception in thread pool-1-thread-2 java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer.unparkSuccessor( AbstractQueuedSynchronizer.java:599) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release( AbstractQueuedSynchronizer.java:1105) at java.util.concurrent.locks.ReentrantLock.unlock( ReentrantLock.java:431) at java.util.concurrent.ThreadPoolExecutor.workerDone( ThreadPoolExecutor.java:568) at java.util.concurrent.ThreadPoolExecutor$Worker.run( ThreadPoolExecutor.java:681) at java.lang.Thread.run(Thread.java:595) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-612) Java SDO Overview doc doesnt address setting of M2_REPO variable
[ https://issues.apache.org/jira/browse/TUSCANY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-612. Resolution: Fixed See http://cwiki.apache.org/confluence/display/TUSCANY/Set+up+SDO+Development+Environment Java SDO Overview doc doesnt address setting of M2_REPO variable Key: TUSCANY-612 URL: https://issues.apache.org/jira/browse/TUSCANY-612 Project: Tuscany Issue Type: Bug Components: Website Affects Versions: Java-M2 Reporter: Kelvin Goodson Fix For: Java-SDO-Mx when initializing a new eclipse environment as per the instructions in the java sdo overview, the eclipse projects generated by the mvn eclipse:eclipse commands don't build until the M2_REPO variable is set. This needs describing in the docvument (instruction outline -- right click a project, properties, build path, libraries, click a library with M2_REPO var referenced, edit, variable, folder, browse to repository (on windows this is c:\Documents and Settings\username\.m2\repository) and set the variable) -- 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: Componentizing our SCA runtime kernel
On 3/13/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ Also, what is a more dynamic invocation mechanism? Most scripting languages out there use dynamic typing - or duck typing for Ruby :) - and do not define interfaces and method signatures. Going further Ruby for example defines a method_missing method that will be invoked if the target component does not implement the method a client is trying to invoke. I think that an SCA runtime assembled to run scripting components will have to support that. Ant may have more insight here as he's been doing some scripting integration work with the Java runtime. Yes I'd really like to get the script components working in a more dynamic way. Other script languages besides Ruby also support 'method missing' type function, Rhino will in their up coming release, many other dynamic languages support things like defining new functions or methods at runtime. For these dynamic languages having to define type information via annotations or side files is unnatural, so I'd like to get to where they're not mandatory. Maybe enable script components to be wired up anywhere and the invocation is just attempted and fails at runtime if the function doesn't exist or the argument types are not what the script expects. Along with getting the Axis2 binding going again in the trunk I also plan to get the script container going again as well and explore some of these things. I have tried in the past but its been difficult to get to work, it looks like some of the recent spec and trunk changes may make some of this easier to do now. ...ant
RE: handling of callbacks with physical wires
Sure, I will do that. Cuurently attach method is agnostic to whether it is forward or callback. If we have specific ones, would the signature change? Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 13, 2007 11:55 AM To: tuscany-dev@ws.apache.org Subject: handling of callbacks with physical wires Hi Meeraj, I've been working on getting the WireAttachers going for PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for callbacks, as they will be used to attach the callback side of a wire. Can you have the marshallers propagate this info as well? While we are on the subject, right now I just have the callbacks attached using the same WA.attach(..) methods as for forward invocations (.cf ConnectorImpl). I'm wondering if we want to add explicit methods for callback attachment as the builders may need to know this specific information to inject the right type of proxy. For example, JDKCallbackInvocationHandler. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message has been checked for all email viruses by MessageLabs. * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX. United Kingdom VAT No. 226 6112 87 This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
Hi Raymond, I have a couple of questions. 1) Are you really just looking for a method something like this: boolean SDOUtil.isSDO(Class interface)? 2) If the answer is yes, where do you get the Class's that you pass to this method, when do you call it, and what do you do if it returns true? 3) Whenever it returns true, doesn't that mean that the client will be working with an SDO and will use SDO APIs? If so, then doesn't the client already know the answer that isSDO() would return. Thanks, Frank Raymond Feng [EMAIL PROTECTED] wrote on 03/12/2007 07:37:50 PM: Hi, Frank. I now see the requirements to recognize the SDO generated classes/interfaces before the SDO TypeHelper is populated. As a result, I would prefer not to rely on TypeHelper.getType(). In my case, we want to introspect java types to find the usages of SDO generated classes/interfaces in the SCA composite and populate the corresponding HelperContext instead of requiring a import.sdo upfront. Does it make sense? Thanks, Raymond - Original Message - From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 23, 2007 3:56 PM Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) Raymond, Yes, null is returned if it's not an SDO type. I'll try to get a more efficient implementation (even if not the final solution) in place soon. Frank. Raymond Feng [EMAIL PROTECTED] wrote on 02/23/2007 05:05:37 PM: Hi, The SCA databinding code introspects java class to recognize a SDO-generated interface/class and get the associated type in a performed way. Yes, I can leave it to the SDO impl and I'll use TypeHelper.getType(Class). I assume null will be returned if the class/interface is not SDO. Thanks, Raymond - Original Message - From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 23, 2007 1:57 PM Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) Hi Raymond, Can you please explain the requirement? Why do you need the type name and why do you instrospect the class? If you want the Type, can't you just call TypeHelper.getType(Class) and leave it up to the SDO impl to do it? Thanks, Frank. Raymond Feng [EMAIL PROTECTED] wrote on 02/23/2007 03:55:00 PM: Hi, Frank. We have checked in the code for SCA databinding to introspect a generated SDO java class. It will be nice to get a fix from SDO. I guess adding a public static field to the generated classes/interfaces will help us recognize it and get the type name. For example, public static final javax.xml.namespace.QName _SDO_TYPE = new javax.xml.namespace.QName(http://customer;, Customer); Thanks, Raymond - Original Message - From: Frank Budinsky (JIRA) tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 4:29 PM Subject: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) [ https://issues.apache.org/jira/browse/TUSCANY-1110?page=com. atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12472943] Frank Budinsky commented on TUSCANY-1110: - Yang, can you explain more about your idea? I also have a couple of ideas for how to speed up TypeHelper.getType(Class): 1) when we move a Java5 dependency, we should generate an annotation in the interface, which we could use at runtime to find the Type. The exact format of the annotation depends on an SDO 3 feature to support Java metadata annotations, which the SDO collaboration is currently considering. 2) before Java5, we could possibly do something like this: step 1) determine the class name from the provided Class. step 2) mangle the name to determine the impl class name (e.g., org.example.Foo - org.example.impl.FooImpl) step 3) create an instance and then call getType() - or better yet, we could change the generator pattern to generate a static method that returns the type - and then call it. I'm sure there are also other possible ways to do this, but the question is what's the priority for this? Does anyone know if the current performance of this method is a concern that needs immediate attention? Improve the performance of TypeHelperImpl.getType(Class) Key: TUSCANY-1110 URL: https://issues.apache.org/jira/browse/TUSCANY-1110 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects
RE: tyring to run spring application
Hi Jim,
When i looked at the spring sample in SCA extension directory i noticed that
there are two file (spring.system.scdl, test.binding.system.scdl ) do i need to
include these files also. I also copied the spring-1.0-incubator-M2.jar file to
this direcoty. but when i started my application i am getting following
exceptions.
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT}implementation.system
[{http://tuscany.apache.org/xmlns/system/1.0-SNAPSHOT}implementation.system]
Context stack trace: [spring.system][spring.implementationLoader]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl..java:90)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:183)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:127)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:70)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl..java:92)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl..java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl..java:109)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java:68)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at
org.apache.tuscany.core.services.extension.AbstractExtensionDeployer.deployExtension(AbstractExtensionDeployer.java:104)
at
org.apache.tuscany.runtime.webapp.WebResourceScanExtender.init(WebResourceScanExtender.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tuscany.core.injection.MethodEventInvoker.invokeEvent(MethodEventInvoker.java:42)
at
org.apache.tuscany.core.implementation.PojoAtomicComponent.init(PojoAtomicComponent.java:94)
at
org.apache.tuscany.core.component.scope.InstanceWrapperImpl.start(InstanceWrapperImpl.java:49)
at
org.apache.tuscany.core.component.scope.ModuleScopeContainer.eagerInitComponents(ModuleScopeContainer.java:145)
at
org.apache.tuscany.core.component.scope.ModuleScopeContainer.onEvent(ModuleScopeContainer.java:72)
at
org.apache.tuscany.spi.component.AbstractSCAObject.publish(AbstractSCAObject.java:94)
at
org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.publish(AbstractCompositeComponent.java:139)
at
org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent.start(AbstractCompositeComponent.java:106)
at
org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(WebappRuntimeImpl.java:127)
at
org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:74)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.tuscany.tomcat.TuscanyHost.addChild(TuscanyHost.java:133)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
[jira] Commented: (TUSCANY-1002) When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded
[ https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480418 ] mat damon commented on TUSCANY-1002: http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/209/actors.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/210/actres3.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/211/actress1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/212/actress1_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/213/actress_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/214/adult1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/215/adult1_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/216/adult1_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/217/adult2_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/218/adult2_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/219/actors.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/220/actres3.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/221/actress1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/222/actress1_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/223/actress_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/224/adult1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/225/adult1_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/226/adult1_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/227/adult2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/228/adult2_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/229/adult2_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/230/adult3.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/231/adult5_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/232/adult6.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/233/adult_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/234/adult_3.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/235/age3_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/236/age3_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/237/aika_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/238/aisan.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/239/aisan_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/240/aisan_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/241/aishwary.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/242/aisian.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/243/akira_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/244/amature2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/245/amatures.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/246/amatures_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/247/amatures_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/248/amauter.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/249/amauter_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/250/america.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/251/american.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/252/american_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/253/american_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/254/ameteur.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/255/ameteur_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/256/ameteur_2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/257/anderso2.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/258/anderso3.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/259/anderson.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/260/anima1_1.html http://gforge.casil.ucdavis.edu/tracker/download.php/30/350039/200134/261/anima1_2.html
[jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480419 ] mat damon commented on TUSCANY-826: --- http://forge.cujae.edu.cu/tracker/download.php/43/248/14/2/index.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/3/index1.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/4/index2.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/5/index4.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/6/index5.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/7/index6.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/8/index7.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/9/index8.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/10/index9.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/11/index10.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/12/index11.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/13/index12.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/14/index13.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/15/index14.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/16/index15.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/17/index16.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/18/index17.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/19/index18.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/20/index19.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/21/index20.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/22/index21.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/23/index22.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/24/index23.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/25/index24.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/26/index25.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/27/index26.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/28/index27.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/29/index28.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/30/index29.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/31/index30.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/32/index31.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/33/index32.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/34/index33.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/35/index34.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/36/index35.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/37/index36.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/38/index37.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/39/index38.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/40/index39.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/41/index40.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/42/index41.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/43/index42.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/44/index43.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/45/index44.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/46/index45.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/47/index46.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/48/index47.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/49/index48.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/50/index49.html http://forge.cujae.edu.cu/tracker/download.php/43/248/14/51/index50.html Containment cycle should result in Exception Key: TUSCANY-826 URL: https://issues.apache.org/jira/browse/TUSCANY-826 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Windows XP, both Sun and IBM JVMs Reporter: Brian Murray Fix For: Java-SDO-Mx Attachments: ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip Near the bottom of page 19 in the 2.0.1 specification it is stated that Containment cannot have cycles. If a set or add would create a containment cycle an exception is thrown. However, I have found that no such exception is thrown. I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-1166) Won't compile with VC6 (again)
Won't compile with VC6 (again) -- Key: TUSCANY-1166 URL: https://issues.apache.org/jira/browse/TUSCANY-1166 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, MSVC++ 6 Reporter: Caroline Maynard Compilation error : SDOXSDWriter.cpp c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : redefinition NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. This is another well-known problem with variable scope in VC6. -- 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-1166) Won't compile with VC6 (again)
[ https://issues.apache.org/jira/browse/TUSCANY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1166: -- Attachment: Tuscany-1166.patch Workaround for VC6 variable scope problem. Won't compile with VC6 (again) -- Key: TUSCANY-1166 URL: https://issues.apache.org/jira/browse/TUSCANY-1166 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, MSVC++ 6 Reporter: Caroline Maynard Attachments: Tuscany-1166.patch Compilation error : SDOXSDWriter.cpp c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : redefinition NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. This is another well-known problem with variable scope in VC6. -- 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-1166) Won't compile with VC6 (again)
[ https://issues.apache.org/jira/browse/TUSCANY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caroline Maynard updated TUSCANY-1166: -- Priority: Critical (was: Major) Won't compile with VC6 (again) -- Key: TUSCANY-1166 URL: https://issues.apache.org/jira/browse/TUSCANY-1166 Project: Tuscany Issue Type: Bug Components: C++ SDO Affects Versions: Cpp-current Environment: Win32, MSVC++ 6 Reporter: Caroline Maynard Priority: Critical Attachments: Tuscany-1166.patch Compilation error : SDOXSDWriter.cpp c:\dev\pecl\sdo\commonj\sdo\sdoxsdwriter.cpp(566) : error C2086: 'j' : redefinition NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. This is another well-known problem with variable scope in VC6. -- 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: [Specs Related] Queries on References
[snip] Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi Sebastien, I agree with your suggestions on two accounts... - its really good to have the model defined around interfaces as it gives the flexibility to improve / modify the implementations we choose over a period of time without the impacting the core which I assume will use only these interfaces. If we use factories to instantiate model objects (i.e. specific implementations of these interfaces) that will keep the core futher away from impacts of changes to implementation of the SPI model. We could probably configure the factory class to be used as part of the scdl - for example as the property of a Loader(s). Hope I am making sense? Yes, making a lot of sense to me... - Specific to the case of references, I did imagine that we may have to clearly abstract out references at componentType level, component level and composite level as there is something specific in 'references' to each level - for example the 'promote' is something that is specific to the composite level. Yes, there's a 4th level in constrainingType, which is the most abstract and does not have a binding or policySets, but I guess we can go step by step so I'm not sure we need it yet... I'll leave it up to you. I have started to make some changes in the SPI model of the kernel. But then, it is not going to be difficult for me to migrate this to your proposed design in the 'assembly'. So I shall continue for now in the kernel unless you see some issues. Good, we'll see if we have the same reading of the spec :). What I posted below was just an initial idea so let me know when you have a code update on your side and we'll see how we can exchange ideas and sync up our interfaces / classes. Thanks. - Venkat The same scheme works for Services as well, so I've added similar Service interfaces + a Wire interface. I'm thinking that all the policy related stuff will end up in a separate module but for now I've created placeholders for policy attachments in o.a.t.policy.model. I'll double check with the spec to see if the same scheme applies to Properties as well. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
Does anybody know what's the Apache process for dealing with stupidity like the referenced comment? Thanks, Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
I have spoken to ant, who has deleted the user. Ant has raised a JIRA, https://issues.apache.org/jira/browse/INFRA-1193, to clean up these 2 JIRAs. Kelvin. On 13/03/07, Frank Budinsky [EMAIL PROTECTED] wrote: Does anybody know what's the Apache process for dealing with stupidity like the referenced comment? Thanks, Frank. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling of callbacks with physical wires
On Mar 13, 2007, at 5:58 AM, Meeraj Kunnumpurath wrote: Sure, I will do that. Cuurently attach method is agnostic to whether it is forward or callback. If we have specific ones, would the signature change? No I think the signature would be the same but some of the meta-data passed as PhysicalWireSource/TargetDefinition may be different for certain implementation types. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class)
Hi, Frank. Please see my comments inline. Thanks, Raymond - Original Message - From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, March 13, 2007 7:08 AM Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) Hi Raymond, I have a couple of questions. 1) Are you really just looking for a method something like this: boolean SDOUtil.isSDO(Class interface)? Yes. But we might need more information such as the QName of the type and the class name of the Factory without looking up the TypeHelper. This way, we can perform the auto-registration of static types without requiring import.sdo or an explicit XXXFactory.INSTANCE.register(HelperContext). 2) If the answer is yes, where do you get the Class's that you pass to this method, when do you call it, and what do you do if it returns true? We introspect java methods to try to figure out if a parameter or return type is SDO. If yes, we'll mark it as SDO databinding. 3) Whenever it returns true, doesn't that mean that the client will be working with an SDO and will use SDO APIs? If so, then doesn't the client already know the answer that isSDO() would return. The client is not the application in this case. It is the Tuscany databinding framework which tries to figure the addtional metadata behind the java class/interface so that we can perform data transformation across different databindings on the wire. Thanks, Frank Raymond Feng [EMAIL PROTECTED] wrote on 03/12/2007 07:37:50 PM: Hi, Frank. I now see the requirements to recognize the SDO generated classes/interfaces before the SDO TypeHelper is populated. As a result, I would prefer not to rely on TypeHelper.getType(). In my case, we want to introspect java types to find the usages of SDO generated classes/interfaces in the SCA composite and populate the corresponding HelperContext instead of requiring a import.sdo upfront. Does it make sense? Thanks, Raymond - Original Message - From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 23, 2007 3:56 PM Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) Raymond, Yes, null is returned if it's not an SDO type. I'll try to get a more efficient implementation (even if not the final solution) in place soon. Frank. Raymond Feng [EMAIL PROTECTED] wrote on 02/23/2007 05:05:37 PM: Hi, The SCA databinding code introspects java class to recognize a SDO-generated interface/class and get the associated type in a performed way. Yes, I can leave it to the SDO impl and I'll use TypeHelper.getType(Class). I assume null will be returned if the class/interface is not SDO. Thanks, Raymond - Original Message - From: Frank Budinsky [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, February 23, 2007 1:57 PM Subject: Re: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) Hi Raymond, Can you please explain the requirement? Why do you need the type name and why do you instrospect the class? If you want the Type, can't you just call TypeHelper.getType(Class) and leave it up to the SDO impl to do it? Thanks, Frank. Raymond Feng [EMAIL PROTECTED] wrote on 02/23/2007 03:55:00 PM: Hi, Frank. We have checked in the code for SCA databinding to introspect a generated SDO java class. It will be nice to get a fix from SDO. I guess adding a public static field to the generated classes/interfaces will help us recognize it and get the type name. For example, public static final javax.xml.namespace.QName _SDO_TYPE = new javax.xml.namespace.QName(http://customer;, Customer); Thanks, Raymond - Original Message - From: Frank Budinsky (JIRA) tuscany-dev@ws.apache.org To: [EMAIL PROTECTED] Sent: Tuesday, February 13, 2007 4:29 PM Subject: [jira] Commented: (TUSCANY-1110) Improve the performance of TypeHelperImpl.getType(Class) [ https://issues.apache.org/jira/browse/TUSCANY-1110?page=com. atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12472943] Frank Budinsky commented on TUSCANY-1110: - Yang, can you explain more about your idea? I also have a couple of ideas for how to speed up TypeHelper.getType(Class): 1) when we move a Java5 dependency, we should generate an annotation in the interface, which we could use at runtime to find the Type. The exact format of the annotation depends on an SDO 3 feature to support Java metadata annotations, which the SDO collaboration is currently considering. 2) before Java5, we could possibly do something like this: step 1) determine the class name from the provided Class. step 2) mangle the name to
[jira] Updated: (TUSCANY-1164) Container of root object is non-null after endLogging()
[
https://issues.apache.org/jira/browse/TUSCANY-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1164:
Fix Version/s: Java-SDO-M3
Container of root object is non-null after endLogging()
---
Key: TUSCANY-1164
URL: https://issues.apache.org/jira/browse/TUSCANY-1164
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Kelvin Goodson
Fix For: Java-SDO-M3
Attachments: RootContainedByChSumTestCase.java
When change logging is turned off on a root data object which has a
ChangeSummary property, the DataObject becomes contained by the
ChangeSummaryImpl (test case to be appended)
I believe that the issue is associated with the assumptions behind the EMF
code at line 272 of ChangeRecorder.java (EMF 2.2.2) in the
consolidateChanges() method
if (eObject.eContainer() == null eObject.eResource() == null)
{
if (originalTargetObjects.contains(eObject))
{
orphanedObjects.add(eObject);
--
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-1002) When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded
[ https://issues.apache.org/jira/browse/TUSCANY-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-1002: --- Comment: was deleted When redefining sdoModel.xsd in XSDHelperImpl, special ChangeSummaryType must be preloaded -- Key: TUSCANY-1002 URL: https://issues.apache.org/jira/browse/TUSCANY-1002 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Reporter: Frank Budinsky Priority: Minor Fix For: Java-SDO-Mx Currently there is a temporary hack in datagraph.xsd (in sdo-api project) to allow us to regenerate sdoModel.xsd with the proper ChangeSummaryType behavior. We need to: 1. Remove the temporary hack in datagraph.xsd which is redefining ChangeSummaryType to be a simple type - i.e., put it back to the way it was defined in the spec. 2. Add code in XSDHelperImpl ctor to preload the special ChangeSummaryType (which is defined in impl/src/main/resources/xml/sdoModelChangeSummary.xsd) when redefineBuiltIn.equals(ModelFactoryImpl,NAMESPACE_URI). With these changes, we will be working as the spec says: The definition of ChangeSummaryType is a complex type in XML (datagraph.xsd), but is treated as a simple data type at the model level. -- 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-826) Containment cycle should result in Exception
[ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Boynes updated TUSCANY-826: -- Comment: was deleted Containment cycle should result in Exception Key: TUSCANY-826 URL: https://issues.apache.org/jira/browse/TUSCANY-826 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-Mx Environment: Windows XP, both Sun and IBM JVMs Reporter: Brian Murray Fix For: Java-SDO-Mx Attachments: ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip Near the bottom of page 19 in the 2.0.1 specification it is stated that Containment cannot have cycles. If a set or add would create a containment cycle an exception is thrown. However, I have found that no such exception is thrown. I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle. -- 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-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:all-tabpanel ] Kelvin Goodson updated TUSCANY-1143: Fix Version/s: Java-SDO-Mx 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-Mx Reporter: Kelvin Goodson Fix For: Java-SDO-Mx 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]
[jira] Updated: (TUSCANY-1129) Multiple Inheritance Broken In Generator Templates
[ https://issues.apache.org/jira/browse/TUSCANY-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1129: Fix Version/s: Java-SDO-Mx Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Multiple Inheritance Broken In Generator Templates -- Key: TUSCANY-1129 URL: https://issues.apache.org/jira/browse/TUSCANY-1129 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M3 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-Mx Attachments: GenMultipleInheritanceTestClasses.java, MemoryModel2JavaGenerator.java TUSCANY-521 exposed a consistent set of integer indices to API visible Properties, and a mapping to the internal EMF indices which had previously been exposed. Some effort was made to preserve the capacity to generate classes that exhibit multiple inheritance, but 1) it was not clear that multiple inheritance was unbroken, and 2) there was no way to describe multiple inheritance as input to the generator. The work that went into the TUSCANY-521 effort to permit generation of SDO classes that exhibit multiple inheritance will be attached here. Completion of this JIRA will require modification of the SDOClass.javajet file to ensure that the internal and external indices are used appropriately when the code path through the generator exercises the multiple inheritance features. Note that this code path also currently exhibits elements of the old generator pattern where EMF code appeared directly in the generated classes. Note also that the multiple inheritance case may cause discontinuous use of index constant values within a given class, hence the reason why the generated internalConverIndex() method is implemented with a switch statement rather than arithmetic. -- 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: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
I deleted the comments. -- Jeremy On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote: I have spoken to ant, who has deleted the user. Ant has raised a JIRA, https://issues.apache.org/jira/browse/INFRA-1193, to clean up these 2 JIRAs. Kelvin. On 13/03/07, Frank Budinsky [EMAIL PROTECTED] wrote: Does anybody know what's the Apache process for dealing with stupidity like the referenced comment? Thanks, Frank. - 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-1122) TypeConversionTestCase fails for JDK 1.4.2
[ https://issues.apache.org/jira/browse/TUSCANY-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1122: Fix Version/s: Java-SDO-Mx Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Java-SDO-M2 TypeConversionTestCase fails for JDK 1.4.2 -- Key: TUSCANY-1122 URL: https://issues.apache.org/jira/browse/TUSCANY-1122 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2, Java-SDO-M3 Environment: IBM JDK 1.4.2 build cn1420-20040626 on Windows also observed on a 1.4.2 linux build svn revision level = 509212 Reporter: Kelvin Goodson Fix For: Java-SDO-Mx Just discovered this, not having build with 1.4.2 for a while. junit.framework.AssertionFailedError : expected:-9223372036854775808 but was:9223372036854775807 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals (Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:136) at junit.framework.Assert.assertEquals(Assert.java:142) at org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java :887) at org.apache.tuscany.sdo.test.TypeConversionTestCase.testTuscany_836(TypeConversionTestCase.java:887) This looks similar to the closed JIRA TUSCANY-712 -- 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: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
Thanks. Could you say where you go to delete existing comments, i couldn't see how to get to a place in JIRA that allows that? ...ant On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I deleted the comments. -- Jeremy On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote: I have spoken to ant, who has deleted the user. Ant has raised a JIRA, https://issues.apache.org/jira/browse/INFRA-1193, to clean up these 2 JIRAs. Kelvin. On 13/03/07, Frank Budinsky [EMAIL PROTECTED] wrote: Does anybody know what's the Apache process for dealing with stupidity like the referenced comment? Thanks, Frank. - 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-1109) TypeHelperImpl#getType(Class) queries wrong scope (EPackage.Registry.INSTANCE) and misses delegate scopes
[ https://issues.apache.org/jira/browse/TUSCANY-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1109: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 TypeHelperImpl#getType(Class) queries wrong scope (EPackage.Registry.INSTANCE) and misses delegate scopes - Key: TUSCANY-1109 URL: https://issues.apache.org/jira/browse/TUSCANY-1109 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Yang ZHONG Fix For: Java-SDO-M3 TypeHelperImpl#getType(Class) queries wrong scope: EPackage.Registry.INSTANCE. And TypeHelperImpl#getType(Class) misses delegate scopes, because getRegistry().values() doesn't include delegateRegistry.values(). -- 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: r516600 - /incubator/tuscany/java/pom.xml
On 3/13/07, Jim Marino [EMAIL PROTECTED] wrote: On Mar 13, 2007, at 3:38 AM, Paul Fremantle wrote: AFAICT the full top-level build is the only way people have found very easy to use so far. To be more accurate, it's the only way people working for a specific vendor have found easy. Others who don't work for that vendor are not having problems. Jim If those people are co-committers on this project I don't see what relevance that has. If they are having problems then they are having problems. This comment is not constructive and not conducive to any of the objectives of an incubating project. Paul Paul, I agree it's not constructive. Not that this is an excuse but I and others on the project are pretty frustrated with all of the non- constructive things that are occurring. My frustration just showed through. Lets try to fix this. Could you say more specifically what it is you are finding frustrating so we can try to resolve the problems? ...ant
[jira] Updated: (TUSCANY-1096) Exception thrown when reference with many multiplicity to the element of anyType
[ https://issues.apache.org/jira/browse/TUSCANY-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1096: Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Exception thrown when reference with many multiplicity to the element of anyType Key: TUSCANY-1096 URL: https://issues.apache.org/jira/browse/TUSCANY-1096 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Fuhwei Lwo Fix For: Java-SDO-M3 Attachments: ReferenceTestCase.java, ReferenceTestCase.java, reftest.xsd, reftest.xsd In the XSD, a reference is defined like xsd:element ref=simple:stockQuote2 maxOccurs=unbounded/ to reference a global element defined like xsd:element name=stockQuote2 type=xsd:anyType/. If the global element type is a fixed type or reference doesn't have many multiplicity, it's working. Only the case like above will throw the following exception. java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addAllUnique(BasicEList.java:774) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddAllUnique(NotifyingListImpl.java:494) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:467) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:396) at org.eclipse.emf.common.util.BasicEList.addAll(BasicEList.java:688) 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:159) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1450) 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.set(DataObjectUtil.java:744) at org.apache.tuscany.sdo.impl.DataObjectImpl.setList(DataObjectImpl.java:536) at org.apache.tuscany.sdo.test.ReferenceTestCase.testDynamic(ReferenceTestCase.java:77) 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) -- 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: tyring to run spring application
Hi,
When i copy the jar in the extension direcotry i am getting the following
exception.
org.apache.tuscany.spi.loader.LoaderException:
com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0xa0 (at char #11,
byte #-1)
Context stack trace: [spring-1.0-incubator-M2]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl..java:136)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java:68)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59)
at
org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
at
org.apache.tuscany.core.services.extension.AbstractExtensionDeployer.deployExtension(AbstractExtensionDeployer.java:104)
at
org.apache.tuscany.runtime.webapp.WebResourceScanExtender.init(WebResourceScanExtender.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
regards,
Muhammad
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Fri 3/9/2007 1:02 AM
To: Waseem, Muhammad (CA - Toronto)
Cc: tuscany-dev@ws.apache.org
Subject: Re: tyring to run spring application
Hi Waseem,
Sorry for the delay, I was tied up at work...The short answer is you need to
make sure the Tuscany Spring Extensions jar is in the extensions lib directory.
The jar adds support for Spring to the SCA kernel. I'll try and respond more
fully tomorrow and help out more.
Jim
On Mar 7, 2007, at 9:38 PM, Waseem, Muhammad ((CA - Toronto)) wrote:
Hi Jim,
My scdl file contain.
?xml version=1.0 encoding=UTF-8?
!--
Author: Muhammad Waseem
Description: Account Service SCA Spring Composite Application
Date Last Modifed: March 02, 2007
Status: Prototype
--
!--
Composite Service:
CheckingAccountService
Services:
CheckingAccountService
Components:
CheckingAccountComponent
--
composite
xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance;
name=checkingaccount
dbsdo:import.sdo
xmlns:dbsdo=http://incubator.apache.org/tuscany/xmlns/databinding/sdo/1.0-incubator-M2;
location=wsdl/services.wsdl /
service name=CheckingAccountService
interface.wsdl
interface=http://checkingaccount.springexample#wsdl.interface(CheckingAccountService)
wsdli:wsdlLocation=http://checkingaccount.springexample
wsdl/services.wsdl
/
binding.ws
endpoint=http://checkingaccount.springexample#wsdl.endpoint(CheckingAccountService/CheckingAccountServiceSOAP)
location=wsdl/services.wsdl
/
!-- Define our component and implementation package --
referencecheckingAccountComponent/reference
/service
component name=checkingAccountComponent
implementation.spring location=applicationContext.xml /
/component
/composite
I am getting following exception.
org.apache.tuscany.runtime.webapp.ServletLauncherInitException:
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org/xmlns/sca/1.0}implementation.spring
[{http://www.osoa.org/xmlns/sca/1.0}implementation.spring]
Context stack trace: [SpringSCA Web Service
Sample][checkingAccountComponent]
at
org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(WebappRuntimeImpl.java:147)
at
org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:74)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4187)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
[jira] Updated: (TUSCANY-1021) CopyHelper and EqualityHelper should handle ChangeSummary
[ https://issues.apache.org/jira/browse/TUSCANY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1021: Fix Version/s: Java-SDO-M3 Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 CopyHelper and EqualityHelper should handle ChangeSummary - Key: TUSCANY-1021 URL: https://issues.apache.org/jira/browse/TUSCANY-1021 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Yang ZHONG Assigned To: Kelvin Goodson Fix For: Java-SDO-M3 ChangeSummary can now be any DataObject attribute, and it's stale through EMF API. Currently, CopyHelper and EqualityHelper heavily depend on EMF. That needs to be patched to support ChangeSummary at any DataObject depth and its summarization if necessary. FYI, 859 has introduced an effort to make ChangeSummary never stale through *SDO* API. -- 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-1006) ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe
[ https://issues.apache.org/jira/browse/TUSCANY-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-1006: Affects Version/s: (was: Java-SDO-Mx) Java-SDO-M3 The above referenced bugzilla is resolved. Is there more to be done here or does that fix this issue? ChangeSummaryImpl.cachedSDOObjectChanges appears to not be thread safe -- Key: TUSCANY-1006 URL: https://issues.apache.org/jira/browse/TUSCANY-1006 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Environment: Sun JDK 1.4.2_11, 2-CPU server Reporter: Ron Gavlin Priority: Critical Fix For: Java-SDO-Mx I have an application in which multiple threads access a shared ChangeSummaryImpl. Each thread invokes ChangeSummaryImpl.getOldValues() repeatedly. This causes one or more of the threads to enter an infinite while (true) - loop in HashMap.get(Object) with the following stack trace: HashMap.get(Object) line: 323 ChangeSummaryImpl.getOldValues(DataObject) line: 481 ... I suspect this occurs because the access to HashMap cachedSDOObjectChanges is not synchronized. I have been unable as of yet to create a simple test case that demonstrates the problem. In the meantime, I will try to implement a short-term fix by changing line 93 of ChangeSummaryImpl from protected HashMap cachedSDOObjectChanges = new HashMap(); to protected Map cachedSDOObjectChanges = Collections.synchronizedMap(new HashMap()); I will let you know if that fixes the problem. Any insight or assistance you can offer concerning this problem is appreciated. This is a show-stopper problem for us. Regards, - 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: [jira] Commented: (TUSCANY-826) Containment cycle should result in Exception
I have a delete link next to the comment - it may be because I have Jira admin rights. However, I couldn't resolve INFRA-1193 so please could you close that. -- Jeremy On Mar 13, 2007, at 9:11 AM, ant elder wrote: Thanks. Could you say where you go to delete existing comments, i couldn't see how to get to a place in JIRA that allows that? ...ant On 3/13/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I deleted the comments. -- Jeremy On Mar 13, 2007, at 8:33 AM, kelvin goodson wrote: I have spoken to ant, who has deleted the user. Ant has raised a JIRA, https://issues.apache.org/jira/browse/INFRA-1193, to clean up these 2 JIRAs. Kelvin. On 13/03/07, Frank Budinsky [EMAIL PROTECTED] wrote: Does anybody know what's the Apache process for dealing with stupidity like the referenced comment? Thanks, Frank. - 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] Updated: (TUSCANY-902) release distributions should have common root folder naming the release
[ https://issues.apache.org/jira/browse/TUSCANY-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-902: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Description: The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that it would be better if all distributions relating to a given release contained all their files in a commonly named root folder. (was: The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that it would be better if all distributions relating to a given release contained all their filles in a commonly named root folder.) Affects Version/s: (was: Java-SCA-Future) Java-SDO-M2 release distributions should have common root folder naming the release --- Key: TUSCANY-902 URL: https://issues.apache.org/jira/browse/TUSCANY-902 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-M3 The discussion at http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that it would be better if all distributions relating to a given release contained all their files in a commonly named root folder. -- 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-901) jar Manifests require Application-Vendor-Id
[ https://issues.apache.org/jira/browse/TUSCANY-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson updated TUSCANY-901: --- Fix Version/s: (was: Java-SDO-Mx) Java-SDO-M3 Affects Version/s: (was: Java-SCA-Future) Java-SDO-M2 jar Manifests require Application-Vendor-Id --- Key: TUSCANY-901 URL: https://issues.apache.org/jira/browse/TUSCANY-901 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Reporter: Kelvin Goodson Priority: Minor Fix For: Java-SDO-M3 The mailing list thread here http://www.mail-archive.com/general@incubator.apache.org/msg11201.html identified that our jar manifest files should have this field -- 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: tyring to run spring application
Hi, I changed the spring.system.scdl file in meta-inf to default.scdl then this exception is gone. but now i am getting following exception org.apache.tuscany.runtime.webapp.ServletLauncherInitException: org.apache.tuscany.spi.loader.MissingResourceException: No location supplied Context stack trace: [Account Service Spring Prototype][AccountServiceComponent] at org.apache.tuscany.runtime.webapp.WebappRuntimeImpl.initialize(WebappRuntimeImpl.java:147) at org.apache.tuscany.runtime.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:74) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4187) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.tuscany.tomcat.TuscanyHost.addChild(TuscanyHost.java:133) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.tuscany.tomcat.TuscanyHost.start(TuscanyHost.java:72) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) From: Waseem, Muhammad (CA - Toronto) [mailto:[EMAIL PROTECTED] Sent: Tue 3/13/2007 12:21 PM To: Jim Marino Cc: tuscany-dev@ws.apache.org Subject: RE: tyring to run spring application Hi, When i copy the jar in the extension direcotry i am getting the following exception. org.apache.tuscany.spi.loader.LoaderException: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0xa0 (at char #11, byte #-1) Context stack trace: [spring-1.0-incubator-M2] at org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl...java:136) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java:68) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59) at org.apache.tuscany.core.implementation.system.loader.SystemCompositeComponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38) at org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159) at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76) at org.apache.tuscany.core.services.extension.AbstractExtensionDeployer.deployExtension(AbstractExtensionDeployer.java:104) at org.apache.tuscany.runtime.webapp.WebResourceScanExtender.init(WebResourceScanExtender.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) regards, Muhammad From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Fri 3/9/2007 1:02 AM To: Waseem, Muhammad (CA - Toronto) Cc: tuscany-dev@ws.apache.org Subject: Re: tyring to run spring application Hi Waseem, Sorry for the delay, I was tied up at work...The short answer is you need to make sure the Tuscany Spring Extensions jar is in the extensions lib directory. The jar adds support for Spring to the SCA kernel. I'll try and respond more fully tomorrow and help out more. Jim On Mar 7, 2007, at 9:38 PM, Waseem, Muhammad ((CA - Toronto)) wrote: Hi Jim,
[jira] Created: (TUSCANY-1167) SDO Codegen generates bad code when the noNotification option is used
SDO Codegen generates bad code when the noNotification option is used - Key: TUSCANY-1167 URL: https://issues.apache.org/jira/browse/TUSCANY-1167 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M3 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-M3 The code generated using the -noNotification option causes the SDO codegen tool to create code that can not be compiled. There is an issue in the basicUnsetx method, where the return statement is excluded. This is because the return has accidentally been included inside the suppress notification condition. The return statement should be outside of this condition. -- 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]
[sca-java-integration-branch] Running JUnit test suites with maven surefire
Hi,
I have experimented to run a collection of test cases as a suite in maven
with surefire 2.3 (which supports JUnit 4.2). The following is an example to
demonstrate how we can achieve it.
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;
// The Runner class from JUnit 4.x
@RunWith(Suite.class)
// The test cases to be included in the suite
@SuiteClasses( {CompositeServiceReferenceTest.class, ComponentTest.class,
ComponentServiceReferenceListTest.class,
CompositeServiceReferenceForRefOverrideTest.class,
ComponentServiceReferenceTest.class,
CompositeOneServiceTest.class, CompositeTest.class,
CompositeOneService2LevelTest.class})
public class SpecAllTestCase {
@BeforeClass
public static void init() {
// We might do SCARuntime.start() here
}
@AfterClass
public static void destroy() {
// We might do SCARuntime.stop() here
}
}
I have a few items to be agreed.
1) What's the naming convention for test suites? Should we name them as
*TestSuite.java? If so, we have to adjust the surefire inclusion pattern
in pom.xml to recognize the test suites. If we're fine with names such as
*AllTestCase.java, then the current pattern can work as-is.
2) For those test cases intended to be run as part of a suite, I guess we
should name them as something like *Test.java which doesn't match the
surefire inclusion pattern. This way, these test cases will not be run out
of the suite. Right?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Some press about SCA and Tuscany
http://www.regdeveloper.co.uk/2007/03/13/sca_for_soa/ -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA] WSDL2Java seems not generating SDO code
Thanks to Sebastien, Simon and Mike for the inputs. I'll try one step at a time. First, I'll try an option to generate SDO as well. Then we can discuss generation from contribution/set more. On 3/12/07, Mike Edwards [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Yang ZHONG wrote: WSDL has schemas and portTypes. WSDL2Java uses SDO CodeGen to compute classes names for schemas and generates classes for portTypes. SDO code seem not actually generated. Is that desired? If not, I can look into how to fix. If yes, are users supposed to use SDO CodeGen themselves? If so, what if users specify options causing different code from what WSDL2Java expects? How do we enable users to reflect the customization to WSDL2Java? Yang, If I remember correctly, the current WSDL2Java tool does not automatically run XSD2Java for all the inline XSDs or all the XSDs referenced from the WSDL. Application developers are responsible to run the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD file. On one hand, it would be nice to support a top-down generation from a WSDL including the closure of all the referenced XSDs. On the other hand if multiple WSDLs reference common XSDs you probably don't want to regenerate code for these XSDs multiple times. Also if an application developer starts to work on an XSD he'll probably want to generate SDOs from it even before writing a WSDL, then later when he generates a Java interface from that WSDL, the interface will have to point to these SDOs... As you noted things will break if incompatible codegen options are used in XSD2Java and WSDL2Java. These issues are actually not specific to WSDL, you can run into similar issues with a graph of XSDs... We should start a discussion to find the best strategy for this codegen: a) Handle generation on an SCA contribution basis (basically you don't gen from individual files but you handle in a single pass ALL relevant files in the contribution, with consistent codegen options and avoiding duplicate gen). b) Or continue with the current approach where the app developer specifies which files to gen from (including support for *.wsdl or *.xsd). c) Or add support for top-down generation of a closure from a WSDL or an XSD. d) Or any other scheme... My preference would be for keeping option (b) and build option (a) on top of it, but I think it'll help to look at how existing similar tools are handling this: How does the current XSD2Java tool handle this? What does it do when you give it an a.xsd containing an import/ of another b.xsd? Does it generate code only for a.xsd? or for both a.xsd and b.xsd? What about the JAXWS tools? Thoughts? One more thought, for option (a) we should be able to reuse the SCA Contribution service to find all the WSDLs and XSDs used in an SCA contribution (as well as the namespaces imported from other SCA contributions) to automate the calls to the WSDL2Java and XSD2Java codegen and generate everything the SCA contribution needs. It seems to me that different usecases apply. It should be possible just to point the tool at some remote WSDL / XSD and generate the required Java files locally, without needing to download the WSDL and XSDs. One of the points of convenience here is that the Java programmer wants as little to do with the WSDL and XSDs as possible - what they are really after are the Java interface files and the SDOs - those are what they will work with. Ideally they DONT want the WSDL and XSDs in their contributions. So an option (at least) should allow the user to request that the tool follows all links and generates all the target entities. Another option should allow for bulk creation - ie a run against not just a single file but a whole series of them - and that the tool should only gen each target once for the whole run (ie spot when the same WSDL or XSD is processed more than once). It seems reasonable to allow just a single file to be processed, but I doubt whether that is what I would want as a default. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
Re: [sca-java-integration-branch] Running JUnit test suites with maven surefire
Hi Raymond
1) What's the naming convention for test suites? Should we name them as
*TestSuite.java? If so, we have to adjust the surefire inclusion pattern
in pom.xml to recognize the test suites. If we're fine with names such as
*AllTestCase.java, then the current pattern can work as-is.
I think *TestSuite.java would make more clear the testcases that had
migrated to the suite notation used by JUnit 4.2. Off course, if it's a lot
of changes to support the name pattern change in the surefire plugin, I'd be
ok with *AllTestCase.java.
2) For those test cases intended to be run as part of a suite, I guess we
should name them as something like *Test.java which doesn't match the
surefire inclusion pattern. This way, these test cases will not be run out
of the suite. Right?
+1
On 3/13/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I have experimented to run a collection of test cases as a suite in maven
with surefire 2.3 (which supports JUnit 4.2). The following is an example
to
demonstrate how we can achieve it.
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;
// The Runner class from JUnit 4.x
@RunWith(Suite.class)
// The test cases to be included in the suite
@SuiteClasses( {CompositeServiceReferenceTest.class, ComponentTest.class,
ComponentServiceReferenceListTest.class,
CompositeServiceReferenceForRefOverrideTest.class,
ComponentServiceReferenceTest.class,
CompositeOneServiceTest.class, CompositeTest.class,
CompositeOneService2LevelTest.class})
public class SpecAllTestCase {
@BeforeClass
public static void init() {
// We might do SCARuntime.start() here
}
@AfterClass
public static void destroy() {
// We might do SCARuntime.stop() here
}
}
I have a few items to be agreed.
1) What's the naming convention for test suites? Should we name them as
*TestSuite.java? If so, we have to adjust the surefire inclusion pattern
in pom.xml to recognize the test suites. If we're fine with names such as
*AllTestCase.java, then the current pattern can work as-is.
2) For those test cases intended to be run as part of a suite, I guess we
should name them as something like *Test.java which doesn't match the
surefire inclusion pattern. This way, these test cases will not be run out
of the suite. Right?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
http://people.apache.org/~lresende
[SDO C++] compilation error
After getting up to date, I'm seeing:
SequenceImpl.cpp
c:\dev\pecl\sdo\commonj\sdo\sequenceimpl.h(344) : error C4716:
'commonj::sdo::SequenceImpl::seq_item::operator=' : must return a value
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
Now the code in question is
// Copy assignment
seq_item operator=(const seq_item sin)
{
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
}
which indeed doesn't return a value. I'm just puzzled why this is only
happening to me. I would raise a JIRA, but it doesn't seem like a VC6
problem, and I can't see why else it would be different.
--
Caroline
Re: [SDO C++] compilation error
On 13/03/07, Caroline Maynard [EMAIL PROTECTED] wrote:
After getting up to date, I'm seeing:
SequenceImpl.cpp
c:\dev\pecl\sdo\commonj\sdo\sequenceimpl.h(344) : error C4716:
'commonj::sdo::SequenceImpl::seq_item::operator=' : must return a value
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
Now the code in question is
// Copy assignment
seq_item operator=(const seq_item sin)
{
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
}
which indeed doesn't return a value. I'm just puzzled why this is only
happening to me. I would raise a JIRA, but it doesn't seem like a VC6
problem, and I can't see why else it would be different.
--
Caroline
This compiles fine on Linux, Nac and Windows using VC Express (V8?). I
assume there is an implied return *this; at the end which the earlier
compiler isn't adding. There is another problem with this in that a correct
implementation should always check that it is not assigning to itself. This
code would fail wih:
seq_item x = blah;
x=x;
It should look something like:
// Copy assignment
seq_item operator=(const seq_item sin)
{
*if(this != sin)*
* {*
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
* }*
* return *this;*
}
I'll fix it up
Cheers,
--
Pete
Re: [SDO C++] compilation error
On 13/03/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 13/03/07, Caroline Maynard [EMAIL PROTECTED] wrote:
After getting up to date, I'm seeing:
SequenceImpl.cpp
c:\dev\pecl\sdo\commonj\sdo\sequenceimpl.h(344) : error C4716:
'commonj::sdo::SequenceImpl::seq_item::operator=' : must return a value
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
Now the code in question is
// Copy assignment
seq_item operator=(const seq_item sin)
{
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
}
which indeed doesn't return a value. I'm just puzzled why this is only
happening to me. I would raise a JIRA, but it doesn't seem like a VC6
problem, and I can't see why else it would be different.
--
Caroline
This compiles fine on Linux, Nac
Nac = Mac :-(
and Windows using VC Express (V8?). I assume there is an implied return
*this; at the end which the earlier compiler isn't adding. There is another
problem with this in that a correct implementation should always check
that it is not assigning to itself. This code would fail wih:
seq_item x = blah;
x=x;
It should look something like:
// Copy assignment
seq_item operator=(const seq_item sin)
{
*if(this != sin)*
* {*
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
* }*
* return *this;*
}
I'll fix it up
Cheers,
--
Pete
--
Pete
[jira] Updated: (TUSCANY-1167) SDO Codegen generates bad code when the noNotification option is used
[ https://issues.apache.org/jira/browse/TUSCANY-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1167: Attachment: 1167.patch This patch moves the return statement outside the suppress notification condition. SDO Codegen generates bad code when the noNotification option is used - Key: TUSCANY-1167 URL: https://issues.apache.org/jira/browse/TUSCANY-1167 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M3 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-M3 Attachments: 1167.patch The code generated using the -noNotification option causes the SDO codegen tool to create code that can not be compiled. There is an issue in the basicUnsetx method, where the return statement is excluded. This is because the return has accidentally been included inside the suppress notification condition. The return statement should be outside of this condition. -- 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: [SDO C++] compilation error
fix checked in to HEAD
On 13/03/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 13/03/07, Pete Robbins [EMAIL PROTECTED] wrote:
On 13/03/07, Caroline Maynard [EMAIL PROTECTED] wrote:
After getting up to date, I'm seeing:
SequenceImpl.cpp
c:\dev\pecl\sdo\commonj\sdo\sequenceimpl.h(344) : error C4716:
'commonj::sdo::SequenceImpl::seq_item::operator=' : must return a
value
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
Now the code in question is
// Copy assignment
seq_item operator=(const seq_item sin)
{
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
}
which indeed doesn't return a value. I'm just puzzled why this is only
happening to me. I would raise a JIRA, but it doesn't seem like a VC6
problem, and I can't see why else it would be different.
--
Caroline
This compiles fine on Linux, Nac
Nac = Mac :-(
and Windows using VC Express (V8?). I assume there is an implied return
*this; at the end which the earlier compiler isn't adding. There is another
problem with this in that a correct implementation should always check
that it is not assigning to itself. This code would fail wih:
seq_item x = blah;
x=x;
It should look something like:
// Copy assignment
seq_item operator=(const seq_item sin)
{
*if(this != sin)*
* {*
if (freeText)
{
delete freeText;
}
if (sin.freeText != 0)
{
freeText = new SDOValue(*sin.freeText);
}
* }*
* return *this;*
}
I'll fix it up
Cheers,
--
Pete
--
Pete
--
Pete
Re: SDO Java M3 content
Just trying to pick this up again having been unwell for most of last week. I've just made a few no-brainer updates to the JIRAs with respect to correct settings for version labels, but I'd like to pin down the content for the next release. In my tidying up of the website content I posted about earlier, I put up a wiki page showing all JIRAs that have been fixed between M2 and now ... http://cwiki.apache.org/confluence/display/TUSCANY/SDO+Java+M3 So clearly they would all be part of the content. I hope these permalinks I copied from the JIRA interface display the same for you as they do for me Here's what's currently marked by the JIRA system as deferred (i.e. unresolved and not marked as SDO-M3) http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210component=12310660component=12310973component=12310802fixfor=12311030fixfor=12312345fixfor=12312232fixfor=12312304fixfor=12312265fixfor=12311062fixfor=12311958fixfor=12312266fixfor=12312094fixfor=12312261fixfor=12312262fixfor=12312038fixfor=12312349fixfor=12312352fixfor=12312353fixfor=12312354fixfor=12312355fixfor=12312356fixfor=12312357fixfor=12312358fixfor=12311926resolution=-1sorter/field=issuekeysorter/order=DESCsorter/field=customfield_12310041sorter/order=ASC And here's what's unresolved and marked for inclusion in M3 ... http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210fixfor=12312317resolution=-1sorter/field=issuekeysorter/order=DESC Please comment on this state and volunteer to pick up any of the issues if you possible can. Regards, Kelvin. On 02/03/07, kelvin goodson [EMAIL PROTECTED] wrote: I did some work yesterday to get the SDO Java JIRAs reflecting the true history of releases to date, so now all the JIRAs that I could edit (not closed) that contributed to SDO Java M2 have a fix version of JAVA-SDO-M2 (I then closed all these), and anything that has been fixed since has a fix version of JAVA-SDO-M3. So with a view to getting an M3 release together we should discuss the content of that release and set the fix version of any unresolved JIRAs that we really want to have in that release to JAVA-SDO-M3. Also, unless anyone has a burning desire to do so, I'm happy to take on the release management role for this milestone. Regards, Kelvin.
Re: [SCA] WSDL2Java seems not generating SDO code
Comments inline Yang ZHONG wrote: Thanks to Sebastien, Simon and Mike for the inputs. I'll try one step at a time. First, I'll try an option to generate SDO as well. Then we can discuss generation from contribution/set more. Great. Thanks Yang! On 3/12/07, Mike Edwards [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Yang ZHONG wrote: WSDL has schemas and portTypes. WSDL2Java uses SDO CodeGen to compute classes names for schemas and generates classes for portTypes. SDO code seem not actually generated. Is that desired? If not, I can look into how to fix. If yes, are users supposed to use SDO CodeGen themselves? If so, what if users specify options causing different code from what WSDL2Java expects? How do we enable users to reflect the customization to WSDL2Java? Yang, If I remember correctly, the current WSDL2Java tool does not automatically run XSD2Java for all the inline XSDs or all the XSDs referenced from the WSDL. Application developers are responsible to run the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD file. On one hand, it would be nice to support a top-down generation from a WSDL including the closure of all the referenced XSDs. On the other hand if multiple WSDLs reference common XSDs you probably don't want to regenerate code for these XSDs multiple times. Also if an application developer starts to work on an XSD he'll probably want to generate SDOs from it even before writing a WSDL, then later when he generates a Java interface from that WSDL, the interface will have to point to these SDOs... As you noted things will break if incompatible codegen options are used in XSD2Java and WSDL2Java. These issues are actually not specific to WSDL, you can run into similar issues with a graph of XSDs... We should start a discussion to find the best strategy for this codegen: a) Handle generation on an SCA contribution basis (basically you don't gen from individual files but you handle in a single pass ALL relevant files in the contribution, with consistent codegen options and avoiding duplicate gen). b) Or continue with the current approach where the app developer specifies which files to gen from (including support for *.wsdl or *.xsd). c) Or add support for top-down generation of a closure from a WSDL or an XSD. d) Or any other scheme... My preference would be for keeping option (b) and build option (a) on top of it, but I think it'll help to look at how existing similar tools are handling this: How does the current XSD2Java tool handle this? What does it do when you give it an a.xsd containing an import/ of another b.xsd? Does it generate code only for a.xsd? or for both a.xsd and b.xsd? What about the JAXWS tools? Thoughts? One more thought, for option (a) we should be able to reuse the SCA Contribution service to find all the WSDLs and XSDs used in an SCA contribution (as well as the namespaces imported from other SCA contributions) to automate the calls to the WSDL2Java and XSD2Java codegen and generate everything the SCA contribution needs. It seems to me that different usecases apply. It should be possible just to point the tool at some remote WSDL / XSD and generate the required Java files locally, without needing to download the WSDL and XSDs. One of the points of convenience here is that the Java programmer wants as little to do with the WSDL and XSDs as possible - what they are really after are the Java interface files and the SDOs - those are what they will work with. Ideally they DONT want the WSDL and XSDs in their contributions. So an option (at least) should allow the user to request that the tool follows all links and generates all the target entities. Another option should allow for bulk creation - ie a run against not just a single file but a whole series of them - and that the tool should only gen each target once for the whole run (ie spot when the same WSDL or XSD is processed more than once). It seems reasonable to allow just a single file to be processed, but I doubt whether that is what I would want as a default. Yours, Mike. +1 to Simon's and Mike's comments. We need to be able to gen from a WSDL/XSD from wherever it is, so the tool should allow: - to pass just a URL to a WSDL/XSD - to specify that you want to follow all links - bulk generation from a set of files (I may be wrong, but I think that our Maven plugin already supports that, I'm not sure about the non-Maven command line tool though) - bulk generation from the set of files (local or remote) referenced by an SCA contribution -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Native M3 release status
On 13/03/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Just a quick update. The doc is in order now (thanks Andy) and the distros are ok on Linux/Mac. I'm having to rework the source distro for Windows as there were some errors in the build settings. A few more minor changes to the build script to make the extensions optional and I'll be done. Cheers, Cool. I just refreshed and it built OK on Linux, except that the PHP extension was not built at all even after doing configure --enable-all-extensions. It does not seem to be built by build.sh either but I guess it's ok... I'm assuming that you're not going to include the PHP extension in the release yet? One minor thing, extensions/ws/service/deploy.sh didn't work for me, the script looks for $APFULLDIR/modules/tuscany/module.xml which does not exist. This looks like I've made a typo in the Makefile.am. I have module_DATA instead of modules_DATA. I've tested the command line and REST samples and they worked. I can help test your release candidate on Linux when it's ready. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: handling of callbacks with physical wires
On Mar 13, 2007, at 4:55 AM, Jim Marino wrote: Hi Meeraj, I've been working on getting the WireAttachers going for PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for callbacks, as they will be used to attach the callback side of a wire. Instead, how about have the PWSD and PWTD with two interceptor chains (forward and callback)? Then WA would just have two methods #attach (PWSD) and #attach(PWTD) for the source (reference) side and target (service) side respectively. Each one would handle attaching both forward and callback chains as needed. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling of callbacks with physical wires
On Mar 13, 2007, at 12:28 PM, Jeremy Boynes wrote: On Mar 13, 2007, at 4:55 AM, Jim Marino wrote: Hi Meeraj, I've been working on getting the WireAttachers going for PhysicalComponentDefinitions. On PhysicalWireDefinition, I've added PhysicalWireSourcetDefinition and PhysicalWireTargetDefinition for callbacks, as they will be used to attach the callback side of a wire. Instead, how about have the PWSD and PWTD with two interceptor chains (forward and callback)? Then WA would just have two methods #attach(PWSD) and #attach(PWTD) for the source (reference) side and target (service) side respectively. Each one would handle attaching both forward and callback chains as needed. +1 this is a simpler approach. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Assembly metadata, was: Queries on References
Jean-Sebastien Delfino wrote: [snip] Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi Sebastien, I agree with your suggestions on two accounts... - its really good to have the model defined around interfaces as it gives the flexibility to improve / modify the implementations we choose over a period of time without the impacting the core which I assume will use only these interfaces. If we use factories to instantiate model objects (i.e. specific implementations of these interfaces) that will keep the core futher away from impacts of changes to implementation of the SPI model. We could probably configure the factory class to be used as part of the scdl - for example as the property of a Loader(s). Hope I am making sense? Yes, making a lot of sense to me... I've created an AssemblyFactory interface. Hope it will help decouple the various modules. I'll try what you're proposing to pass the factory to the loaders once I manage to get past the circular dependencies with Deployer that I mentioned in http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED] (and are preventing me to build the loaders at the moment). If anybody has any ideas on how to best refactor this to avoid circular dependencies, let's talk about it. - Specific to the case of references, I did imagine that we may have to clearly abstract out references at componentType level, component level and composite level as there is something specific in 'references' to each level - for example the 'promote' is something that is specific to the composite level. Yes, there's a 4th level in constrainingType, which is the most abstract and does not have a binding or policySets, but I guess we can go step by step so I'm not sure we need it yet... I'll leave it up to you. I have started to make some changes in the SPI model of the kernel. But then, it is not going to be difficult for me to migrate this to your proposed design in the 'assembly'. So I shall continue for now in the kernel unless you see some issues. Good, we'll see if we have the same reading of the spec :). What I posted below was just an initial idea so let me know when you have a code update on your side and we'll see how we can exchange ideas and sync up our interfaces / classes. Thanks. - Venkat The same scheme works for Services as well, so I've added similar Service interfaces + a Wire interface. I'm thinking that all the policy related stuff will end up in a separate module but for now I've created placeholders for policy attachments in o.a.t.policy.model. I'll double check with the spec to see if the same scheme applies to Properties as well. I've added Properties and also interfaces for Component, ComponentType and ConstrainingType referencing the interfaces above. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r517376 - in /incubator/tuscany/java/sca/kernel/core/src: main/java/org/apache/tuscany/core/marshaller/extensions/ main/java/org/apache/tuscany/core/marshaller/extensions/instancefacto
On Mar 12, 2007, at 1:28 PM, [EMAIL PROTECTED] wrote: incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/ tuscany/core/model/physical/instancefactory/ InjectionSiteType.java (with props) How about using j.l.annotation.ElementType? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Representation of Property default value
As part of the effort to componentize some of the Kernel I'm trying to
make sure that the representation of assembly metadata is independent of
XML and just came across this in o.a.t.spi.model.Property:
import org.w3c.dom.Document;
public Document getDefaultValue() {
return defaultValue;
}
This is going to be problematic when you're not loading the assembly
metadata from SCDL/XML, and looks less than ideal to me in other cases
where the defaultValue of the property is just a simple type, or
initialized from introspecting a component implementation artifact.
Any thoughts on a better way to represent a property value? Could we
leverage the databinding framework here to decouple the metadata from XML?
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representation of Property default value
Hi,
I don't think we can completely avoid XML because the property values are
provided as XML in the SCDL. But we could accomodate the various cases in
the model using a neutral way. I propose to use the following:
DataType dataType; // Decribe the property type with databinding
Object defaultValue; // The default value for the property conforming to
its data type
1) For a property loaded from SCDL:
dataType (physical=org.w3c.dom.Document.class,
databinding=org.w3c.dom.Node)
defaultValue (an instance of org.w3c.dom.Document)
2) For a simple String property introspected from Java:
dataType(physical=java.lang.String.class,
databinding=java.lang.Object)
defaultValue(an instance of String, such as 123)
3) For a complex SDO (or JAXB) property introspected from Java:
dataType(physical=customer.Customer.class,
databinding=commonj.sdo.DataObject)
defaultValue(an instance of customer.Customer, a generated SDO class)
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, March 13, 2007 1:24 PM
Subject: Representation of Property default value
As part of the effort to componentize some of the Kernel I'm trying to
make sure that the representation of assembly metadata is independent of
XML and just came across this in o.a.t.spi.model.Property:
import org.w3c.dom.Document;
public Document getDefaultValue() {
return defaultValue;
}
This is going to be problematic when you're not loading the assembly
metadata from SCDL/XML, and looks less than ideal to me in other cases
where the defaultValue of the property is just a simple type, or
initialized from introspecting a component implementation artifact.
Any thoughts on a better way to represent a property value? Could we
leverage the databinding framework here to decouple the metadata from XML?
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Kernel Alpha2 Release
I would like to start thinking about the next release of kernel. Based on the work being done around federation, it seems that multi- VM support is the key feature we should look to enable. This will allow us to demonstrate the high-value areas of SCA, particularly around distributed assembly. In addition, we should have a simplified extension model and classloader isolation in place. In terms of timing, I thought sometime around the first or second week in April would be ideal, as a few of us will be demonstrating these features at the ServerSide Symposium next week. I think we may also be able to get some bindings and extensions out around the same time or shortly after. I was thinking: Spring, Groovy, JPA, and Hessian to start. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour
Hi I remember Dan discussing this on the list before but I can't put my finger on the thread If I run the databinding WS tests without including the factory for the WSDL XML types in the composite... dbsdo:import.sdo factory= org.apache.tuscany.sca.itest.databinding.services.ServicesFactory/ Then the web service call fails with the following: java.lang.ClassCastException: org.apache.tuscany.sdo.util.BasicSequenceincompat ible with org.apache.tuscany.sca.itest.databinding.types.PersonType at $Proxy26.greetPersonType(Unknown Source) at org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl. greetPersonType(GreeterServiceClientImpl.java:47) ... In the case where I am getting the error Tuscany can't convert the wrapped return type from the call back to the type expected in the client. This is clearly something to do with Tuscany not having the correct types registered (adding the above import fixes it). But the thing that confuses me is that it only fails on processing the return message in the client. It has quite happily 1/ Converted the request message into a wrapped message on the client 2/ Converted the wrapped message back into the required message on the server 3/ Converted the response message into a wrapped response on the server only to fail at the final hurdle when trying to unwrap the response on the client. So it seems to be able to do quite a lot without the imported information. Why is it required for the last step. I'm happy to look into this if there is not an obvious answer. If nothing else we need better error messages here. Regards Simon
Re: svn commit: r517891 - /incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/tuscany/core/model/physical/instancefactory/InjectionSiteMapping.java
Meeraj asked me offline what I meant by using ElementType so I added
this strawman for a mapping from something in SCA land (a callback,
reference or property value) to a Java injection site (field, method,
ctrArg). In the end it doesn't use ElementType at all...
Meeraj, I hope this makes sense :-)
--
Jeremy
On Mar 13, 2007, at 2:50 PM, [EMAIL PROTECTED] wrote:
Author: jboynes
Date: Tue Mar 13 14:50:31 2007
New Revision: 517891
URL: http://svn.apache.org/viewvc?view=revrev=517891
Log:
strawman for mapping values to injection sites for the injection
provider
Added:
incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/
tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java (with props)
Added: incubator/tuscany/java/sca/kernel/core/src/main/java/org/
apache/tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/kernel/
core/src/main/java/org/apache/tuscany/core/model/physical/
instancefactory/InjectionSiteMapping.java?view=autorev=517891
==
--- incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/
tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java (added)
+++ incubator/tuscany/java/sca/kernel/core/src/main/java/org/apache/
tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java Tue Mar 13 14:50:31 2007
@@ -0,0 +1,115 @@
+/*
+ * 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.core.model.physical.instancefactory;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public class InjectionSiteMapping {
+/**
+ * Identifier in SCA terms of the source of the value that
will be injected.
+ */
+public static class ValueSource {
+public static enum ValueSourceType {
+CALLBACK,
+REFERENCE,
+PROPERTY
+}
+
+private ValueSourceType valueType;
+private String name;
+
+public ValueSourceType getValueType() {
+return valueType;
+}
+
+public void setValueType(ValueSourceType valueType) {
+this.valueType = valueType;
+}
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+/**
+ * Abstraction for a site where a value can be injected.
+ */
+public static abstract class Site {
+}
+
+public static class FieldSite extends Site {
+private String name;
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+public static class MethodSite {
+private String name;
+
+public String getName() {
+return name;
+}
+
+public void setName(String name) {
+this.name = name;
+}
+}
+
+public static class ConstructorSite extends Site {
+private int paramIndex;
+
+public int getParamIndex() {
+return paramIndex;
+}
+
+public void setParamIndex(int paramIndex) {
+this.paramIndex = paramIndex;
+}
+}
+
+private ValueSource source;
+private Site site;
+
+public ValueSource getSource() {
+return source;
+}
+
+public void setSource(ValueSource source) {
+this.source = source;
+}
+
+public Site getSite() {
+return site;
+}
+
+public void setSite(Site site) {
+this.site = site;
+}
+}
Propchange: incubator/tuscany/java/sca/kernel/core/src/main/java/
org/apache/tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java
--
svn:eol-style = native
Propchange: incubator/tuscany/java/sca/kernel/core/src/main/java/
org/apache/tuscany/core/model/physical/instancefactory/
InjectionSiteMapping.java
--
svn:keywords = Rev Date
[jira] Commented: (TUSCANY-1164) Container of root object is non-null after endLogging()
[
https://issues.apache.org/jira/browse/TUSCANY-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480568
]
Yang ZHONG commented on TUSCANY-1164:
-
Thanks to Kelvin for pinpointing the EMF problem.
I have verified and entered an EMF bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=177235
Container of root object is non-null after endLogging()
---
Key: TUSCANY-1164
URL: https://issues.apache.org/jira/browse/TUSCANY-1164
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-M3
Reporter: Kelvin Goodson
Fix For: Java-SDO-M3
Attachments: RootContainedByChSumTestCase.java
When change logging is turned off on a root data object which has a
ChangeSummary property, the DataObject becomes contained by the
ChangeSummaryImpl (test case to be appended)
I believe that the issue is associated with the assumptions behind the EMF
code at line 272 of ChangeRecorder.java (EMF 2.2.2) in the
consolidateChanges() method
if (eObject.eContainer() == null eObject.eResource() == null)
{
if (originalTargetObjects.contains(eObject))
{
orphanedObjects.add(eObject);
--
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-java-integration-branch] Missing WSDL type imports causes aymetrical behviour
Hi, The ClassCastException will only happen if we try to get the child element out of the repsonse wrapper (which is an instance of AnyTypeDataObjectImpl because the model is not registered with SDO runtime) and cast it to a generated SDO interface. If the ServiceFactory is not registered, the data (from the inline schema of the WSDL) are then represented by org.apache.tuscany.sdo.impl.AnyTypeDataObjectImpl which doesn't have problems to convert to XML or vice versa. But now the child of AnyTypeDataObjectImpl is BasicSequence instead of the real PersonType since the types are not known. It's very common that we define XSD elements and types in the inline schemas of WSDL. These need to be registered so SDO runtime can work correctly. I could try to make your special case working (your wsdl only has element definitions) and I don't see much value. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, March 13, 2007 2:51 PM Subject: [sca-java-integration-branch] Missing WSDL type imports causes aymetrical behviour Hi I remember Dan discussing this on the list before but I can't put my finger on the thread If I run the databinding WS tests without including the factory for the WSDL XML types in the composite... dbsdo:import.sdo factory= org.apache.tuscany.sca.itest.databinding.services.ServicesFactory/ Then the web service call fails with the following: java.lang.ClassCastException: org.apache.tuscany.sdo.util.BasicSequenceincompat ible with org.apache.tuscany.sca.itest.databinding.types.PersonType at $Proxy26.greetPersonType(Unknown Source) at org.apache.tuscany.sca.itest.sdodatabinding.GreeterServiceClientImpl. greetPersonType(GreeterServiceClientImpl.java:47) ... In the case where I am getting the error Tuscany can't convert the wrapped return type from the call back to the type expected in the client. This is clearly something to do with Tuscany not having the correct types registered (adding the above import fixes it). But the thing that confuses me is that it only fails on processing the return message in the client. It has quite happily 1/ Converted the request message into a wrapped message on the client 2/ Converted the wrapped message back into the required message on the server 3/ Converted the response message into a wrapped response on the server only to fail at the final hurdle when trying to unwrap the response on the client. So it seems to be able to do quite a lot without the imported information. Why is it required for the last step. I'm happy to look into this if there is not an obvious answer. If nothing else we need better error messages here. Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1168) Type.isSequenced() returns wrong value for my XSD
Type.isSequenced() returns wrong value for my XSD - Key: TUSCANY-1168 URL: https://issues.apache.org/jira/browse/TUSCANY-1168 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Raymond Feng For the following XSD: schema targetNamespace=http://www.example.com/wrapper; xmlns=http://www.w3.org/2001/XMLSchema; !-- Faults -- element name=op complexType sequence maxOccurs=unbounded element name=message minOccurs=1 type=string / element name=symbol minOccurs=1 maxOccurs=3 type=string / /sequence /complexType /element element name=opResponse complexType sequence maxOccurs=1 element name=price minOccurs=1 maxOccurs=unbounded type=string / /sequence /complexType /element /schema I assume the type for op element is sequenced since maxOccurs 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]
[jira] Created: (TUSCANY-1169) Property.getType() throws ClassCastException if the property is from AnyDataObjectType.getInstanceProperties()
Property.getType() throws ClassCastException if the property is from AnyDataObjectType.getInstanceProperties() -- Key: TUSCANY-1169 URL: https://issues.apache.org/jira/browse/TUSCANY-1169 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Reporter: Raymond Feng I try to load the following XML document without defining XSD against the XSDHelper. ?xml version=1.0 encoding=UTF-8? p:op xmlns:p=http://www.example.com/wrapper; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.example.com/wrapper wrapper.xsd messagemessage/message symbolsymbol/symbol messagemessage1/message symbolsymbol1/symbol symbolsymbol2/symbol /p:op Then when I call: List properties = rootObject.getInstanceProperties(); For a property in the list, calling p.getType() gives me a ClassCastException. -- 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-1170) The YearMonthDay property type throws format exception when retrieving long value
The YearMonthDay property type throws format exception when retrieving long value - Key: TUSCANY-1170 URL: https://issues.apache.org/jira/browse/TUSCANY-1170 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Environment: n/a Reporter: David T. Adcox Retrieval of a YearMonthDay SDO property type via the getLong() method causes a java.lang.NumberFormatException. The value is converted to a String when set. The Long.parseLong() doesn't like the alpha characters encoded in the string created. The DataObjectUtil getLong method seems to be ready to accept a Date object type, but the storage type is String, so that path is not taken. Attached is a sample class and schema that will demonstrate the problem. -- 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-1170) The YearMonthDay property type throws format exception when retrieving long value
[ https://issues.apache.org/jira/browse/TUSCANY-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1170: Attachment: Test1170.java api_test.xsd The YearMonthDay property type throws format exception when retrieving long value - Key: TUSCANY-1170 URL: https://issues.apache.org/jira/browse/TUSCANY-1170 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M3 Environment: n/a Reporter: David T. Adcox Attachments: api_test.xsd, Test1170.java Retrieval of a YearMonthDay SDO property type via the getLong() method causes a java.lang.NumberFormatException. The value is converted to a String when set. The Long.parseLong() doesn't like the alpha characters encoded in the string created. The DataObjectUtil getLong method seems to be ready to accept a Date object type, but the storage type is String, so that path is not taken. Attached is a sample class and schema that will demonstrate the problem. -- 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: Assembly metadata, was: Queries on References
Hi, I added the namespace support for the SAX handler and a minor fix to call setXSDType against Property. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, March 13, 2007 1:08 PM Subject: Assembly metadata, was: Queries on References Jean-Sebastien Delfino wrote: [snip] Jean-Sebastien Delfino wrote: Venkata Krishnan wrote: Hi Sebastien, I agree with your suggestions on two accounts... - its really good to have the model defined around interfaces as it gives the flexibility to improve / modify the implementations we choose over a period of time without the impacting the core which I assume will use only these interfaces. If we use factories to instantiate model objects (i.e. specific implementations of these interfaces) that will keep the core futher away from impacts of changes to implementation of the SPI model. We could probably configure the factory class to be used as part of the scdl - for example as the property of a Loader(s). Hope I am making sense? Yes, making a lot of sense to me... I've created an AssemblyFactory interface. Hope it will help decouple the various modules. I'll try what you're proposing to pass the factory to the loaders once I manage to get past the circular dependencies with Deployer that I mentioned in http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED] (and are preventing me to build the loaders at the moment). If anybody has any ideas on how to best refactor this to avoid circular dependencies, let's talk about it. - Specific to the case of references, I did imagine that we may have to clearly abstract out references at componentType level, component level and composite level as there is something specific in 'references' to each level - for example the 'promote' is something that is specific to the composite level. Yes, there's a 4th level in constrainingType, which is the most abstract and does not have a binding or policySets, but I guess we can go step by step so I'm not sure we need it yet... I'll leave it up to you. I have started to make some changes in the SPI model of the kernel. But then, it is not going to be difficult for me to migrate this to your proposed design in the 'assembly'. So I shall continue for now in the kernel unless you see some issues. Good, we'll see if we have the same reading of the spec :). What I posted below was just an initial idea so let me know when you have a code update on your side and we'll see how we can exchange ideas and sync up our interfaces / classes. Thanks. - Venkat The same scheme works for Services as well, so I've added similar Service interfaces + a Wire interface. I'm thinking that all the policy related stuff will end up in a separate module but for now I've created placeholders for policy attachments in o.a.t.policy.model. I'll double check with the spec to see if the same scheme applies to Properties as well. I've added Properties and also interfaces for Component, ComponentType and ConstrainingType referencing the interfaces above. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Representation of Property default value
Raymond Feng wrote:
Hi,
I don't think we can completely avoid XML because the property values
are provided as XML in the SCDL. But we could accomodate the various
cases in the model using a neutral way. I propose to use the following:
DataType dataType; // Decribe the property type with databinding
Object defaultValue; // The default value for the property
conforming to its data type
1) For a property loaded from SCDL:
dataType (physical=org.w3c.dom.Document.class,
databinding=org.w3c.dom.Node)
defaultValue (an instance of org.w3c.dom.Document)
2) For a simple String property introspected from Java:
dataType(physical=java.lang.String.class,
databinding=java.lang.Object)
defaultValue(an instance of String, such as 123)
3) For a complex SDO (or JAXB) property introspected from Java:
dataType(physical=customer.Customer.class,
databinding=commonj.sdo.DataObject)
defaultValue(an instance of customer.Customer, a generated SDO class)
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, March 13, 2007 1:24 PM
Subject: Representation of Property default value
As part of the effort to componentize some of the Kernel I'm trying
to make sure that the representation of assembly metadata is
independent of XML and just came across this in
o.a.t.spi.model.Property:
import org.w3c.dom.Document;
public Document getDefaultValue() {
return defaultValue;
}
This is going to be problematic when you're not loading the assembly
metadata from SCDL/XML, and looks less than ideal to me in other
cases where the defaultValue of the property is just a simple type,
or initialized from introspecting a component implementation artifact.
Any thoughts on a better way to represent a property value? Could we
leverage the databinding framework here to decouple the metadata from
XML?
Thanks,
--
Jean-Sebastien
I'm not sure :)
I guess we can do one of the following:
- always represent the data as expected by the particular component
implementation (but I'm not sure how this is going to work for
constrainingTypes, which can be used to shape multiple components)
- use a canonical form independent of the particular component
implementation and the databinding it uses; this will allow admin tools
for example to retrieve/update property values in a generic way,
independent of the implementation type
- have a mix like your cases 1/2/3 but then it's not ideal, as support
for component implementations will need to know about the particular
serializations of the assembly model, and other usages of the model like
admin tools for example will need to know about the implementation types
and the databindings that they're dragging along.
Is there actually a way in SCA 1.0 to specify a default value using Java
annotations? I know that the SCA assembly spec 1.0 allows for
implementations to be configured without SCDL in general, but I can't
find any annotations to support that in the Java CI common annotation
and component implementation specs. Did I miss them? or has this been
pushed out of 1.0?
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
SDO C++ creating property problem
I created a new type on a DataFactory, for example
...
dataFactory-addType(MyNameSpace, MyRoot);
const Type myType = dataFactory-getType(MyNameSpace, MyRoot);
const Type intType = dataFactory-getType(commonj.sdo, Integer);
//then I try to add some integer properties to this type
dataFactory-addPropertyToType(myType, getColumnName(statement, 1),
intType);
std::cout Properties count = myType.getProperties().size() \n;
dataFactory-addPropertyToType(myType, getColumnName(statement, 2),
intType);
std::cout Properties count = myType.getProperties().size() \n;
...
}
//where getColumnName function is defined as:
std::string getColumnName(HSTMT statement, int column) {
SQLPOINTER sqlPtr = 0;
char strAux[1];
SQLSMALLINT length = 0;
SQLColAttributeA(statement, column, SQL_DESC_BASE_COLUMN_NAME, strAux,
1, (SQLSMALLINT*) length, NULL); //get the string length
length++;
sqlPtr = (char*) malloc(length*sizeof(char)); //alloc the enough memory
to place the string characters
SQLColAttributeA(statement, column, SQL_DESC_BASE_COLUMN_NAME, sqlPtr,
length, (SQLSMALLINT*) length, NULL); //get the string from the db
std::string ret = (char*) sqlPtr; //create a new string object from a
char pointer
return ret;
}
Unfortunately the output is:
Properties count = 1
Properties count = 1
instead of
Properties count = 1
Properties count = 2
I've checked if the function getColumnName isn't returning strings with the
same value, but it is not, they are different strings!!
Though I tried an strange approach and it's solving the problem for while,
that is to instantiate a new string on memory:
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 1)), intType);
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 2)), intType);
Can anybody tell why it's happening?
Adriano Crestani
Re: Representation of Property default value
Hi,
1) For the canonical form, don't you think we have it with DOM?
2) In Java, you have three styles to define a property using @Property:
* A public or protected field
* A setter method
* A parameter for the constructor
I don't see Java CI talks about how to supply the default value for a
property. One thought is that the initial value for the holding field might
do, such as:
1)
@Property
public String myProp=ABC;
2)
private String myProp=ABC;
@Property
public void setMyProp(String value) {
this.myProp=value;
}
3)
private String myProp=ABC;
public MyServiceImpl(@Property(name=myProp) String value) {
this.myProp=value;
}
For case 3, I'm not sure how do we pass in the value if no property value
is provided by the component definition.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, March 13, 2007 9:48 PM
Subject: Re: Representation of Property default value
Raymond Feng wrote:
Hi,
I don't think we can completely avoid XML because the property values are
provided as XML in the SCDL. But we could accomodate the various cases in
the model using a neutral way. I propose to use the following:
DataType dataType; // Decribe the property type with databinding
Object defaultValue; // The default value for the property conforming
to its data type
1) For a property loaded from SCDL:
dataType (physical=org.w3c.dom.Document.class,
databinding=org.w3c.dom.Node)
defaultValue (an instance of org.w3c.dom.Document)
2) For a simple String property introspected from Java:
dataType(physical=java.lang.String.class,
databinding=java.lang.Object)
defaultValue(an instance of String, such as 123)
3) For a complex SDO (or JAXB) property introspected from Java:
dataType(physical=customer.Customer.class,
databinding=commonj.sdo.DataObject)
defaultValue(an instance of customer.Customer, a generated SDO class)
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, March 13, 2007 1:24 PM
Subject: Representation of Property default value
As part of the effort to componentize some of the Kernel I'm trying to
make sure that the representation of assembly metadata is independent of
XML and just came across this in o.a.t.spi.model.Property:
import org.w3c.dom.Document;
public Document getDefaultValue() {
return defaultValue;
}
This is going to be problematic when you're not loading the assembly
metadata from SCDL/XML, and looks less than ideal to me in other cases
where the defaultValue of the property is just a simple type, or
initialized from introspecting a component implementation artifact.
Any thoughts on a better way to represent a property value? Could we
leverage the databinding framework here to decouple the metadata from
XML?
Thanks,
--
Jean-Sebastien
I'm not sure :)
I guess we can do one of the following:
- always represent the data as expected by the particular component
implementation (but I'm not sure how this is going to work for
constrainingTypes, which can be used to shape multiple components)
- use a canonical form independent of the particular component
implementation and the databinding it uses; this will allow admin tools
for example to retrieve/update property values in a generic way,
independent of the implementation type
- have a mix like your cases 1/2/3 but then it's not ideal, as support for
component implementations will need to know about the particular
serializations of the assembly model, and other usages of the model like
admin tools for example will need to know about the implementation types
and the databindings that they're dragging along.
Is there actually a way in SCA 1.0 to specify a default value using Java
annotations? I know that the SCA assembly spec 1.0 allows for
implementations to be configured without SCDL in general, but I can't find
any annotations to support that in the Java CI common annotation and
component implementation specs. Did I miss them? or has this been pushed
out of 1.0?
Thanks,
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO C++ creating property problem
Hey,
Now I was checking if the properties were correctly added to the type and I
got something strange:
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 1)), intType);
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 2)), intType);
// on my test the column names returned by the getColumnName function are
respectively ID and DESCR
...
//then I checked if the properties were correctly added with this loop:
int m;
commonj::sdo::PropertyList list = myType.getProperties();
for (m = 0 ; m list.size() ; m++) {
std::cout list[m].getName() \n;
}
The output should be:
ID
DESCR
But it's outputting:
ID
DESCR
I don't know from where this four = are coming from, cause I already have
checked with a debugger and the strings ID and DESCR are being added and
there is no '=' ('\205' as shown on the debugger) character in it.
Is this a bug?
Adriano Crestani
//as I've already said I'm adding the properties this way:
On 3/14/07, Adriano Crestani [EMAIL PROTECTED] wrote:
I created a new type on a DataFactory, for example
...
dataFactory-addType(MyNameSpace, MyRoot);
const Type myType = dataFactory-getType(MyNameSpace, MyRoot);
const Type intType = dataFactory-getType(commonj.sdo, Integer);
//then I try to add some integer properties to this type
dataFactory-addPropertyToType(myType, getColumnName(statement, 1),
intType);
std::cout Properties count = myType.getProperties().size()
\n;
dataFactory-addPropertyToType(myType, getColumnName(statement, 2),
intType);
std::cout Properties count = myType.getProperties().size()
\n;
...
}
//where getColumnName function is defined as:
std::string getColumnName(HSTMT statement, int column) {
SQLPOINTER sqlPtr = 0;
char strAux[1];
SQLSMALLINT length = 0;
SQLColAttributeA(statement, column, SQL_DESC_BASE_COLUMN_NAME,
strAux, 1, (SQLSMALLINT*) length, NULL); //get the string length
length++;
sqlPtr = (char*) malloc(length*sizeof(char)); //alloc the enough
memory to place the string characters
SQLColAttributeA(statement, column, SQL_DESC_BASE_COLUMN_NAME, sqlPtr,
length, (SQLSMALLINT*) length, NULL); //get the string from the db
std::string ret = (char*) sqlPtr; //create a new string object from a
char pointer
return ret;
}
Unfortunately the output is:
Properties count = 1
Properties count = 1
instead of
Properties count = 1
Properties count = 2
I've checked if the function getColumnName isn't returning strings with
the same value, but it is not, they are different strings!!
Though I tried an strange approach and it's solving the problem for while,
that is to instantiate a new string on memory:
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 1)), intType);
dataFactory-addPropertyToType(myType, *(new
std::string(getColumnName(statement, 2)), intType);
Can anybody tell why it's happening?
Adriano Crestani
Re: Assembly metadata, was: Queries on References
Raymond Feng wrote: Hi, I added the namespace support for the SAX handler and a minor fix to call setXSDType against Property. Thanks, Raymond Thanks, with your change I was able to put QNames in the test .composite and .constrainingType files and get them loaded correctly. I'll do some more tests with property elements and types tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
