Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib , libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to solve issue #3) Did we run into any other big issues? No, that's about it. 2. XSD loading can be done by convention (schemas for the runtime are always in a folder called 'xsd' 1. Could be solved in a similar way by only loading libraries in a folder called ??? 3. Can be solved by just ignoring the load errors/issuing a warning rather than giving up 4. Can be solved by solution to 3. I recall now why 3. was a big problem. Windows sometimes throws up an error dialog when the load fails so it was not just a case of the runtime handling the load failure so we had to disable the extension. Cheers, -- Pete -- Pete Pete, just summarizing so that I understand. It seems there are two parts to this. A/ Building and installing an extension in order that it can be consumed by the runtime. Building and installing extensions is potentially a separate activity from building and installing the runtime itself. Looking at the M2 download they all come together at the moment. B/ Optionally consuming/enabling an extension
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib , libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to solve issue #3) Did we run into any other big issues? No, that's about it. 2. XSD loading can be done by convention (schemas for the runtime are always in a folder called 'xsd' 1. Could be solved in a similar way by only loading libraries in a folder called ??? 3. Can be solved by just ignoring the load errors/issuing a warning rather than giving up 4. Can be solved by solution to 3. I recall now why 3. was a big problem. Windows sometimes throws up an error dialog when the load fails so it was not just a case of the runtime handling the load failure so we had to disable the extension. Cheers, -- Pete -- Pete Pete, just summarizing so that I understand. It seems there are two parts to this. A/ Building and installing an extension in order that it can be consumed by the runtime. Building and installing
Re: [jira] Commented: (TUSCANY-949) Incorrect set of extensions published to the maven repo
On 11/29/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Nov 29, 2006, at 4:00 AM, ant elder wrote: Looks like that answers all the questions and sounds convincing to me. We discussed doing this the other day and agreed it needed doing and based on that Simon went ahead and did the work for it, so I think we should go ahead and apply this to M2 now. Unless there are any other concerns I'll do this tonight. We didn't agree it needed doing. I still don't think it does as I see no downside to not making this change. I have concerns that using profiles this way will cause problems (e.g. what happens if two profiles include different modules) and I was hoping Simon had a better solution. I think this approach is confusing for users as it's not obvious which modules get built and which don't. I am also concerned that there has not been enough testing given we are so close to release. I'm not concerned enough though to veto such a change so if you think it's the right thing to do then go ahead. I would suggest waiting to see what the consensus really is. -- Jeremy I'm reluctant to commit this while you're so against it, but I'm not sure I understand your concerns. We did clearly tell Simon to go and make a patch to do this: jboynes simonnash: if you want something different, please give us a patch for the build to build it as YOU want it and: simonnash so in building the release I would expect to select a subset of all available modules and copy those selected modules into contrib and also deploy htem to maven jboynes patches welcome simonnash ok i will do what I can. any help from others will be appreciated. and then the IRC chat summary posted to the dev list clearly said it was happening: there was some discussion around what Tuscany jars are released as part of M2 into the maven repository. Currently everything in the Tuscany build is released, should that be trimmed to only those things that we want to say are ready? Simon is going to create a patch to the build to make this possible. No one questioned that and in good faith he's gone off and made a patch as requested. With the current Axiom issue we have a bit of time now, I've tried the patch and seems to work fine, would you give it a test? What other testing would you like to see? Another thing I think we should remember is that this patch is from a new contributor so we should be receptive so as to encourage further participation. I'd really appreciate others comments on if we should apply this. ...ant
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to solve issue #3) Did we run into any other big issues? No, that's about it. 2. XSD loading can be done by convention (schemas for the runtime are always in a folder called 'xsd' 1. Could be solved in a similar way by only loading libraries in a folder called ??? 3. Can be solved by just ignoring the load errors/issuing a warning rather than giving up 4. Can be solved by solution to 3. I recall now why 3. was a big problem. Windows sometimes throws up an error dialog when the load fails so it was not just a case of the runtime handling the load failure so we had to disable the extension.
Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to solve issue #3) Did we run into any other big issues? No, that's about it. 2. XSD loading can be done by convention (schemas for the runtime are always in a folder called 'xsd' 1. Could be solved in a similar way by only loading libraries in a folder called ??? 3. Can be solved by just ignoring the load errors/issuing a warning rather than giving up 4. Can be solved by solution to 3.
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to solve issue #3) Did we run into any other big issues? No, that's about it. 2. XSD loading can be done by convention (schemas for the runtime are always in a folder called 'xsd' 1.
Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g. libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the runtime 4. The system admin / installer should be able to disable extensions that won't load because their dependencies are not there (I'm not yet convinced that this is still an issue if we manage to
Re: [C++] Binding/Language Extensions - packaging
snip I would package the cpp language extension as cpp/ bin/ lib/ include/ xsd/ extension/ The bin, lib, include are exactly what you would expect from a package that you might want to build against. The extension/ folder would hold the library that implements the extension interface and xsd holds... well xsds! How would extensions be disabled? Rename the extension dir? Remove any symlinks in extension/ ? Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: snip I would package the cpp language extension as cpp/ bin/ lib/ include/ xsd/ extension/ The bin, lib, include are exactly what you would expect from a package that you might want to build against. The extension/ folder would hold the library that implements the extension interface and xsd holds... well xsds! How would extensions be disabled? Rename the extension dir? Remove any symlinks in extension/ ? Remove symlink or the dll on windows -- Pete
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs, we need to load XSDs that contribute to SCDL, and leave other XSDs under the extension directory alone 3. Extensions that cannot be loaded because some of their dependencies are not there should no break the
Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language :) I'm aware of the following issues: 1. We need the runtime to load extension libs only, not other libs under the extension directory which are not actual extensions 2. Same for XSDs,
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows. I agree that we should do better than renaming to .disabled, but I'd like to understand better the actual issues that we faced before inventing yet another XML based runtime configuration language
Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows.
Re: [C++] Binding/Language Extensions - packaging
On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2 release on Windows.
What next for SDO Java?
It's a good time to take stock of where we are and where we want to go with SDO for Java. Clearly there's work to be done with heading towards an implementation of the SDO Java 2.1 spec [1,2,3], but what else might we do; where do you want to take things? [1] the new 2.1 spec http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1 [2] For those with a good knowledge of the 2.1 spec you can see what's changed here http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL_changebars.pdf?version=1 [3] And for a brief digest of the changes see here ... http://osoa.org/download/attachments/519/SDO_2.1_Features_Nov_2006.pdf?version=1 Does anyone have any bright ideas about value add features that they'd like to suggest and ideally implement? While the spec work is all well and good, I'm sure there are people out there who have said It would be really neat if ... Please feel free say it out loud by posting to the list. On the other hand, more tests/samples are always welcome. Similarly documentation. For my part I've been thinking about the new spec element for compliant change summary serialization, and I plan to put some ideas on the wiki soon. In addition to the 2.1 work, we have a stack of JIRAs that if anyone is feeling so inclined would be great to reduce. I've taken a scan through to see which might have a low bar of entry, in that the skills required are general skills rather than SDO implementation knowledge. Please feel free to scan them yourself if you feel you'd like more of a challenge. Alternatively, as I have a reasonable grasp of the current JIRAs, if there are skills you have to offer, I could probably tell you reasonably quickly where they might be applied. If there's any maven experts out there TUSCANY-313 is a good candidate. Same goes for TUSCANY-901and 902. Similarly some discussion on how we might structure our code to take account of the fact that the Interface2JavaGenerator class has a Java 5 dependency, yet the rest has a 1.4.2 + prereq would be good (TUSCANY-257). Maybe someone could attack TUSCANY-303, where the Java generator can only handle a single namespace to package mapping, and this needs to be extended to a list of such mappings (I'm not sure how deep that one gets into the generator itself, but may be some investigation might result in a partial patch ) Tuscany 578 is a bucket defect for recording occasions where we throw the wrong type of exceptions, while not very exciting, it might be a good candidate for someone to experience the process of submitting a patch to an open source project for the first time. I would have thought that the new feature TUSCANY-893 wouldn't be too onerous -- if you take a look and want to discuss it on the list that would be great. And of course I don't wany to denigrate you, the Tuscany community's skills. I'm sure there are those of you out there who are quite capable of diving into some of the other issues, but like I said, these are the ones that don't require you to get your head round much of the Tuscany Java SDO implementation. Please don't be shy. If you think you can help we'd love to hear from you. Regards, Kelvin.
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Folks, Can't you just use maven's exclusion mechanism: http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_exclusion to exclude the specific version of axiom and add a specific dependency on the new one? thanks, dims On 11/29/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Aha! so there's a catch. We still haven't started the process for a Axis2 1.1.1. Hoping to do that with a thorough JIRA scrub this week or early next week. To see what needs to be fixed for a quick 1.1.1 release. Will let you all know when we have some idea. thanks, dims On 11/29/06, Simon Nash [EMAIL PROTECTED] wrote: Thanks, Dims. We will need a new release of Axis2 as well, since the POMs in Axis2 1.1 point to Axiom 1.2. Will this be available at the same time as the new release of Axiom? Simon Davanum Srinivas wrote: Thanks Jim/Jeremy :) Please look at the pom's in the svn. the SNAPSHOT jars are here: http://ws.zones.apache.org/repository/org.apache.ws.commons.axiom/jars/ thanks, dims On 11/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Nov 28, 2006, at 1:24 PM, Davanum Srinivas wrote: Folks, Fact #1: WSCOMMONS-131 is fixed in SVN. Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is to do the release this week. What's the ruckus all about? (Please don't make me all the emails :) Well, now, nothing :-) Are there any artifacts for 1.2.1 that we can take a look at? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
I've tried out the suggested fixes and I have run into a big problem. By proxying the inbound wire of the composite reference, there is no databinding interceptor in the invocation chain. This causes Axis2TargetInvoker to choke. Exception java.lang.IllegalArgumentException Exception message: Can't handle mixed payloads betweem OMElements and other types. java.lang.IllegalArgumentException: Can't handle mixed payloads betweem OMElements and other types. at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationClient (Axis2TargetInvoker.java) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget( Axis2TargetInvoker.java:70) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke( Axis2TargetInvoker.java:107) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke( InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke( SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke( AbstractInboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke( JDKInboundInvocationHandler.java:108) How do we get the databinding transformation into this flow? The DatabindingInterceptor currently requires an outbound wire from the client. Dynamically creating an outbound wire for a non-SCA client and connecting it to the composite reference sounds like a major piece of work. Is there a simpler solution?
Re: database update problem
OK, I can set any attribute ; )
You got an exception? I'm getting no exception here, the new item is just
not being updated in the database.
Adriano Crestani
On 11/30/06, Kevin Williams [EMAIL PROTECTED] wrote:
Hello Adriano,
No. It should not be working this way and thanks for finding this bug!
The fact that a new Cart was added to the graph is recorded in the SDO
change summary and indicates to the DAS that an INSERT should be
generated. However, it looks like the DAS then generates the insert
statement based solely on attributes that have been set. I just tested
this and an invalid insert statement is generated which results in the
database throwing a SQLException; I assume you get a similar error.
I think there are two possible correct behaviors for this:
1. The DAS always generates a complete INSERT statement using
whatever values exist in the new DataObject. If a property has
not been set then these values will be null for object properties
or default values for primitive properties.
2. The DAS generates a partial INSERT whenever there are set
properties and generates a complete INSERT otherwise
My guess is that the first option will be most straightforward for users
to understand and will lead to least astonishment.
Any thoughts folks?
In the meantime, Adriano, can you set some property of the new item you
want inserted?
I created TUSCANY-957 to track this.
Thanks.
--
Kevin
Adriano Crestani wrote:
I created one table called cart with an auto-increment key on mysql,
then
I defined this table on the config.xml as containing an auto-increment
key.
Using SCO/DAS I create one tuple of the cart table, but no attribute
is
set. I know DAS only update one attribute tuple only if it has been
modified
and if no attribute is set the tuple should not be added in the
database,
but it is implicit that at least one attribute will be set, in this
case the
primary key, cause it is set as auto-increment key. Unfortunately the
tuple
is not being added in the database : (. Should it be working this way?
Here is the code that tries to create a new cart tuple in the database:
public void newCart() {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());
Command command = das.getCommand(all carts);
DataObject allCarts = command.executeQuery();
DataObject newCart = allCarts.createDataObject(CART);
allCarts.getList(CART).add(newCart);
das.applyChanges(allCarts);
}
How the table cart is being declared in the mysql database:
CREATE TABLE CART (
ID INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
SUB_TOTAL DOUBLE,
TAX DOUBLE,
TOTAL DOUBLE,
CONFIRMED INTEGER
);
ShoppingCartConfig.xml:
?xml version=1.0 encoding=ASCII?
Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;
Command name=all carts SQL=SELECT * FROM CART kind=Select/
Table tableName=CART
Column columnName=ID primaryKey=true generated=true/
/Table
/Config
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: database update problem
It is strange that you do not see an exception since the generated
INSERT statement is not valid.
Everything should work fine if you use the work-around and set any
attribute to some value.
Thanks.
--
Kevin
Adriano Crestani wrote:
OK, I can set any attribute ; )
You got an exception? I'm getting no exception here, the new item is just
not being updated in the database.
Adriano Crestani
On 11/30/06, Kevin Williams [EMAIL PROTECTED] wrote:
Hello Adriano,
No. It should not be working this way and thanks for finding this bug!
The fact that a new Cart was added to the graph is recorded in the SDO
change summary and indicates to the DAS that an INSERT should be
generated. However, it looks like the DAS then generates the insert
statement based solely on attributes that have been set. I just tested
this and an invalid insert statement is generated which results in the
database throwing a SQLException; I assume you get a similar error.
I think there are two possible correct behaviors for this:
1. The DAS always generates a complete INSERT statement using
whatever values exist in the new DataObject. If a property has
not been set then these values will be null for object properties
or default values for primitive properties.
2. The DAS generates a partial INSERT whenever there are set
properties and generates a complete INSERT otherwise
My guess is that the first option will be most straightforward for users
to understand and will lead to least astonishment.
Any thoughts folks?
In the meantime, Adriano, can you set some property of the new item you
want inserted?
I created TUSCANY-957 to track this.
Thanks.
--
Kevin
Adriano Crestani wrote:
I created one table called cart with an auto-increment key on mysql,
then
I defined this table on the config.xml as containing an auto-increment
key.
Using SCO/DAS I create one tuple of the cart table, but no attribute
is
set. I know DAS only update one attribute tuple only if it has been
modified
and if no attribute is set the tuple should not be added in the
database,
but it is implicit that at least one attribute will be set, in this
case the
primary key, cause it is set as auto-increment key. Unfortunately the
tuple
is not being added in the database : (. Should it be working this way?
Here is the code that tries to create a new cart tuple in the
database:
public void newCart() {
DAS das = DAS.FACTORY.createDAS
(getClass().getClassLoader().getResourceAsStream(ShoppingCartConfig.xml
),
getConnection());
Command command = das.getCommand(all carts);
DataObject allCarts = command.executeQuery();
DataObject newCart = allCarts.createDataObject(CART);
allCarts.getList(CART).add(newCart);
das.applyChanges(allCarts);
}
How the table cart is being declared in the mysql database:
CREATE TABLE CART (
ID INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
SUB_TOTAL DOUBLE,
TAX DOUBLE,
TOTAL DOUBLE,
CONFIRMED INTEGER
);
ShoppingCartConfig.xml:
?xml version=1.0 encoding=ASCII?
Config xmlns=http:///org.apache.tuscany.das.rdb/config.xsd;
Command name=all carts SQL=SELECT * FROM CART kind=Select/
Table tableName=CART
Column columnName=ID primaryKey=true generated=true/
/Table
/Config
-
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: Test case fails: LoanAppConversationTestCase
Hmm, not sure what's going on. I don't get the failure. It almost sounds like the container is not getting the remove call from the target invoker, which could happen if the target invoker did not see a sequence end in the message, which in turn could happen if the end interceptor were not there or not working properly. Could you make sure that the core/implementation.scdl in the target of core includes ConversationWirePostProcessor? On 11/29/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I'm seeing the following test case failure in trunk code. Raymond --- T E S T S --- Running loanappconversation.LoanAppConversationTestCase Applied: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, s tatus: open Loan approved: false Sleeping to let cancel complete ... Cancelled: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, status: cancelled Trying to use the closed loan in the ended conversation ... Closed: Loan application: null, term: 0, status: closed junit.framework.AssertionFailedError: Target should not be found at junit.framework.Assert.fail(Assert.java:47) at loanappconversation.LoanAppConversationTestCase.test (LoanAppConversat ionTestCase.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute( JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:269) at org.apache.maven.surefire.booter.SurefireBooter.main( SurefireBooter.j ava:788) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.375 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[jira] Resolved: (TUSCANY-885) Property DataObject.getProperty(String propertyName) should return null if the property cannot be found
[ http://issues.apache.org/jira/browse/TUSCANY-885?page=all ] Kelvin Goodson resolved TUSCANY-885. Resolution: Fixed fixed in 478825 Property DataObject.getProperty(String propertyName) should return null if the property cannot be found --- Key: TUSCANY-885 URL: http://issues.apache.org/jira/browse/TUSCANY-885 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Assigned To: Kelvin Goodson Priority: Minor Fix For: Java-Mx Attachments: DAS_885.txt, tuscany-885.patch Based on SDO 2.01 specification, DataObject.getProperty(String propertyName) should return null if the property cannot be found. Unfortunately, it returns IlegalArgumentException now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-932) Invoking DataObject.isSet(String path) with invalid path would result in NPE
[ http://issues.apache.org/jira/browse/TUSCANY-932?page=all ] Kelvin Goodson resolved TUSCANY-932. Resolution: Fixed fixed in 478825 Invoking DataObject.isSet(String path) with invalid path would result in NPE Key: TUSCANY-932 URL: http://issues.apache.org/jira/browse/TUSCANY-932 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Attachments: DataObjectUtil.932, final.patch, RevisedPatchWithTest The 2.1 spec didn't mention what outcome should be when invoking DataObject.isSet(String path) with an invalid path so I am not sure whether NPE is acceptable. The spec did mention bold?Note that attempts to modify read-only properties (using set, unset or delete) cause an exception./bold -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 29/11/06, Pete Robbins [EMAIL PROTECTED] wrote: This was introduced when opentype support was added. Is it needed? Don't know. What do you expect to be returned when you try to get the type of entry?? I've considered your question, and I can't see a valid alternative. I don't intend to surface it through the PHP APIs, because we can exploit dynamic typing there, but I'll go and fix up all my big switches to handle the OpenDataObjectType case. There is another aspect to this - when the document containing the open content is written out or serialized, it contains a lot of xsi:type=OpenDataObject attributes. I can't see any use for these, and they look fussy and complicated. Do you agree they can and should be eliminated? If so I'll raise a JIRA. Example input (where all the types are open): content type=xhtml xml:lang=en xml:base=http://diveintomark.org/;http://diveintomark.org/ div xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml p i[Update: The Atom draft is finished.]/i /p div class=myclass pHello/p /div /div /content example output: content type=xhtml lang=en base= http://diveintomark.org/;langen/langbasehttp://diveintomark.org//basehttp://diveintomark.org/ div xsi:type=OpenDataObject p xsi:type=OpenDataObject i xsi:type=OpenDataObject[Update: The Atom draft is finished.]/i /p div xsi:type=OpenDataObject class=myclass classmyclass/class p xsi:type=OpenDataObjectHello/p /div /div /content You'll no doubt notice a second problem with the output :-). I'll be raising a JIRA for that one too. -- Caroline
[jira] Created: (TUSCANY-958) NPE generated during a property set of a static SDO
NPE generated during a property set of a static SDO --- Key: TUSCANY-958 URL: http://issues.apache.org/jira/browse/TUSCANY-958 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Environment: N/A Reporter: David T. Adcox When a property is set on a static SDO object, a Null Pointer Exception is thrown. This will only occur if the property is being set for the second time, the initial set of the property works. The problem is caused by some erroneous code in the DataObjectImpl class. In the inverseAdd(Object,int,ChangeContext) method, the local variable, changeContextImpl is retrieved from a local method initializeChangeContext(ChangeContext). Then, immediately following this line of code, the same variable is set again by way of a cast of a parameter to the method. In some instances, the value being passed is null, so when the value is used later, an NPE will occur. It seems the cast-set is possibly an old remnant of code from before the creation of the InitializeChangeContext method. This method properly handles the creation of the ChangeContext and works fine, we simply need to comment out the cast-set line of code. A similar behavior is found in inverseRemove(Object,Object,int,Class, ChangeContext), so it should be fixed, as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
This I think highlights a problem with the spec around using CurrentCompositeContext from unmamanged code in general...a locate service only returns half of an invocation chain since the source is not a component and is unmamanged code. Can you describe you client code, is it a JSP or is it from a component? Jim On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote: I've tried out the suggested fixes and I have run into a big problem. By proxying the inbound wire of the composite reference, there is no databinding interceptor in the invocation chain. This causes Axis2TargetInvoker to choke. Exception java.lang.IllegalArgumentException Exception message: Can't handle mixed payloads betweem OMElements and other types. java.lang.IllegalArgumentException: Can't handle mixed payloads betweem OMElements and other types. at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCli ent (Axis2TargetInvoker.java) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget( Axis2TargetInvoker.java:70) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke( Axis2TargetInvoker.java:107) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke( InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke( SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke( AbstractInboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke( JDKInboundInvocationHandler.java:108) How do we get the databinding transformation into this flow? The DatabindingInterceptor currently requires an outbound wire from the client. Dynamically creating an outbound wire for a non-SCA client and connecting it to the composite reference sounds like a major piece of work. Is there a simpler solution? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 30/11/06, Caroline Maynard [EMAIL PROTECTED] wrote: On 29/11/06, Pete Robbins [EMAIL PROTECTED] wrote: This was introduced when opentype support was added. Is it needed? Don't know. What do you expect to be returned when you try to get the type of entry?? I've considered your question, and I can't see a valid alternative. I don't intend to surface it through the PHP APIs, because we can exploit dynamic typing there, but I'll go and fix up all my big switches to handle the OpenDataObjectType case. That's the conclusion I came to as well though this may mean that there is a hole in the spec here. There is another aspect to this - when the document containing the open content is written out or serialized, it contains a lot of xsi:type=OpenDataObject attributes. I can't see any use for these, and they look fussy and complicated. Do you agree they can and should be eliminated? If so I'll raise a JIRA. Yes, there should be no need for them. Example input (where all the types are open): content type=xhtml xml:lang=en xml:base=http://diveintomark.org/;http://diveintomark.org/ div xmlns=http://www.w3.org/1999/xhtml; http://www.w3.org/1999/xhtml p i[Update: The Atom draft is finished.]/i /p div class=myclass pHello/p /div /div /content example output: content type=xhtml lang=en base= http://diveintomark.org/;langen/langbasehttp://diveintomark.org/ /basehttp://diveintomark.org/ div xsi:type=OpenDataObject p xsi:type=OpenDataObject i xsi:type=OpenDataObject[Update: The Atom draft is finished.]/i /p div xsi:type=OpenDataObject class=myclass classmyclass/class p xsi:type=OpenDataObjectHello/p /div /div /content You'll no doubt notice a second problem with the output :-). I'll be raising a JIRA for that one too. Ah a test!! Would it be that classs is serialized as both an attribute and an element?? -- Caroline -- Pete
[jira] Commented: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec
[ http://issues.apache.org/jira/browse/TUSCANY-578?page=comments#action_12454700 ] Kelvin Goodson commented on TUSCANY-578: Transferring in TUSCANY-951 here's the report == Calling set() with an invalid property name results in a NullPointerException. For example: dataObject.setInt(invalidProperty, 5); results in: java.lang.NullPointerException at org.apache.tuscany.sdo.util.DataObjectUtil.getSetValue(DataObjectUtil.java:1440) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:537) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:526) === and my duplicated comments === .. the spec isn't specific about the type of exception that should be thrown in this case, and the changes made under TUSCANY-885 have altered the behaviour of the tuscany implementation without violating the spec. We need to review in general whether we should take the performance hit of catching and translating Exceptions to be more specific about issues. === Exceptions thrown by SDO runtime not the same as defined in the spec Key: TUSCANY-578 URL: http://issues.apache.org/jira/browse/TUSCANY-578 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Brian Murray Priority: Minor Fix For: Java-Mx Attachments: DataObjectUtil.patch On page 27 of V2.01 of the spec, specific exceptions are listed for certain kinds of errors. In some cases, a different exception is thrown (each case will be added as a subtask). Either the specification or the implementation should be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany WSDL2Java
I've been playing with the BigBank sample and have added a fault to the AccountService's withdraw operation. After changing the AccountService.wsdl (attached), the Tuscany WSDL2Java no longer works. (Exception from the build is below.) When I took a quick look at the code, it seemed that the Tuscany code does some configuration of the axis2 code generation and then delegates the majority of the work to it. Does anyone have any ideas of what's going on here? The axis code is looking in a map of QName to Name but the only map that's been populated is a map of QName to SDODataBindingTypeMappingEntry objects. The WSDL2Java from axis2 seems to work okay with the same WSDL. On a somewhat related note, what is the intended relationship between the Tuscany WSDL2Java and Java2WSDL tools to the tools provided by axis2? Thanks! [INFO] Generating Java service interfaces from /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account [INFO] [INFO] Trace java.lang.IllegalArgumentException: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) ... 19 more Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1618) at
Re: Creating proxies (fix for TUSCANY-862)
On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote: This I think highlights a problem with the spec around using CurrentCompositeContext from unmamanged code in general...a locate service only returns half of an invocation chain since the source is not a component and is unmamanged code. Can you describe you client code, is it a JSP or is it from a component? That shouldn't matter should it? I think Greg's problem is that there is a data incompatibility between the source side (the supplied Java interface) and the target side (the WS reference). Normally the connector fixes this by adding a transform interceptor to convert from the Object on the source side to the OMElement on the target side.However, locateService bypasses the connector so this does not get done. I think Greg's proposal is right - create a degenerate outbound wire and then connect it to the target's inbound one. We know we needed to do that for policy at some point but it looks like we'll have to do it sooner due to this transform issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
O.K that's why I asked about what the source side looked like. A degenerate outbound wire seems right. One thing on this is can we cache the degenerate wire so the wire only need to be constructed once while the runtime is in operation? We have the problem I outlined, e.g. if the target is expecting to be in a transactional context and the source never manually sets one up... Jim On Nov 30, 2006, at 9:10 AM, Jeremy Boynes wrote: On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote: This I think highlights a problem with the spec around using CurrentCompositeContext from unmamanged code in general...a locate service only returns half of an invocation chain since the source is not a component and is unmamanged code. Can you describe you client code, is it a JSP or is it from a component? That shouldn't matter should it? I think Greg's problem is that there is a data incompatibility between the source side (the supplied Java interface) and the target side (the WS reference). Normally the connector fixes this by adding a transform interceptor to convert from the Object on the source side to the OMElement on the target side.However, locateService bypasses the connector so this does not get done. I think Greg's proposal is right - create a degenerate outbound wire and then connect it to the target's inbound one. We know we needed to do that for policy at some point but it looks like we'll have to do it sooner due to this transform issue. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-931) Sequence.add(int index, String propertyName, Object value) is not functioning correctly
[ http://issues.apache.org/jira/browse/TUSCANY-931?page=comments#action_12454705 ] Kelvin Goodson commented on TUSCANY-931: Without having reviewed this issue in detail, it's worth capturing the observation that this property has a . in it, so its worth bearing in mind that there's a slim chance that the root cause might possibly be something different from the indexing issue it might seem to be, and more related to TUSCANY-935 or other paths with dots reports. Sequence.add(int index, String propertyName, Object value) is not functioning correctly --- Key: TUSCANY-931 URL: http://issues.apache.org/jira/browse/TUSCANY-931 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2, Java-Mx Environment: No specific environment Reporter: David T. Adcox Attachments: DefectTestApp.java The Sequence.add(int index, String propertyName, Object value) throws a java.lang.RuntimeException. Here is a stack trace from this issue: Exception in thread main java.lang.RuntimeException: Invalid entry feature 'Customer.multi' at org.eclipse.emf.ecore.util.BasicFeatureMap.validate(BasicFeatureMap.java:87) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:661) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:384) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:368) at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:645) at org.eclipse.emf.ecore.util.BasicFeatureMap.doAdd(BasicFeatureMap.java:547) at org.eclipse.emf.ecore.util.BasicFeatureMap.add(BasicFeatureMap.java:1097) at org.apache.tuscany.sdo.util.BasicSequence.add(BasicSequence.java:100) at com.ibm.sdo.test.DefectTestApp.main(DefectTestApp.java:60) The add(String propertyName, Object value) method seems to be functioning fine using the same Sequence object. In tracing this issue through EMF, it seems a validate method in the BasicFeatureMap object is failing in the base case and throwing the exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
I've been using a JSP to test this. At this point I'm not sure how much restricting the client to an SCA component helps because the locateService is still dynamic. Anyway the spec says locateService is available to non-SCA clients. On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote: This I think highlights a problem with the spec around using CurrentCompositeContext from unmamanged code in general...a locate service only returns half of an invocation chain since the source is not a component and is unmamanged code. Can you describe you client code, is it a JSP or is it from a component? Jim On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote: I've tried out the suggested fixes and I have run into a big problem. By proxying the inbound wire of the composite reference, there is no databinding interceptor in the invocation chain. This causes Axis2TargetInvoker to choke. Exception java.lang.IllegalArgumentException Exception message: Can't handle mixed payloads betweem OMElements and other types. java.lang.IllegalArgumentException: Can't handle mixed payloads betweem OMElements and other types. at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCli ent (Axis2TargetInvoker.java) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget( Axis2TargetInvoker.java:70) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke( Axis2TargetInvoker.java:107) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke( InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke( SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke( AbstractInboundInvocationHandler.java:60) at org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke( JDKInboundInvocationHandler.java:108) How do we get the databinding transformation into this flow? The DatabindingInterceptor currently requires an outbound wire from the client. Dynamically creating an outbound wire for a non-SCA client and connecting it to the composite reference sounds like a major piece of work. Is there a simpler solution? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Using Axis2C 0.95 or later..
Hi all, I've just tracked down a bug that's turned up in Axis2C 0.95 - most of our web service calls are fine, but the samples that call out to the external www.webservicex.net services (CppBigBank, RubyBigBank, PythonWeatherForecast) fail due to a missing HTTP SOAPAction header. I've raised this at http://issues.apache.org/jira/browse/AXIS2C-437 and attached a patch that fixes it there. Cheers Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Binding/Language Extensions - packaging
Simon Laws wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having to go tweak XML configuration files If I remember correctly, renaming the dlls to .disabled was a last minute change to work around DLL loading errors with our M2
Re: [SDO C++] Thread safety ?
On 21/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote: As far as SDO itself is concerned, I think we would be OK if the user of SDO could guarantee that whenever an SDO artifact (data factory, data object, type, XSDHelper ...) is created then that artifact will be used _exclusively_ by the thread that created it. If that's acceptable to you then I'll check the code to ensure that my claim is correct. Yes, that's how it would be. The SDO for PHP implementation doesn't keep references to Tuscany objects in static data. As you observed earlier we will need to resolve the localtime issue. I'll raise a JIRA for that. Outside of SDO we will also need to check the various libraries that we depend on. You mentioned libxml2 but there is also zlib and iconv too. Based on a quick look at the libxml2 reference that you supplied we wll need a small change to the SDO build process but also possibly some code changes too. Both zlib and iconv are also part of the normal PHP environment, because libxml2 depends on them, so I don't expect issues with them. But FYI, zlib has a faq: http://www.zlib.net/zlib_faq.html#faq21 As for iconv, I think that libxml2 will use whatever iconv implementation it finds on the platform, which is not necessarily libiconv, so a general statement may not be possible. -- Caroline
Re: Creating proxies (fix for TUSCANY-862)
- Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, November 30, 2006 9:10 AM Subject: Re: Creating proxies (fix for TUSCANY-862) On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote: This I think highlights a problem with the spec around using CurrentCompositeContext from unmamanged code in general...a locate service only returns half of an invocation chain since the source is not a component and is unmamanged code. Can you describe you client code, is it a JSP or is it from a component? That shouldn't matter should it? I think Greg's problem is that there is a data incompatibility between the source side (the supplied Java interface) and the target side (the WS reference). Normally the connector fixes this by adding a transform interceptor to convert from the Object on the source side to the OMElement on the target side.However, locateService bypasses the connector so this does not get done. I think Greg's proposal is right - create a degenerate outbound wire and then connect it to the target's inbound one. We know we needed to do that for policy at some point but it looks like we'll have to do it sooner due to this transform issue. So when the degenerate outbound wire is created and connected, we need to trigger PostWireProcessor to deal with this newly-created dynamic wire. Right? The databinding framework needs to be notified so that it can add the corresponding interceptor to deal with the transformation. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
On Nov 30, 2006, at 9:21 AM, Greg Dritschler wrote:
I've been using a JSP to test this. At this point I'm not sure how
much
restricting the client to an SCA component helps because the
locateService
is still dynamic. Anyway the spec says locateService is available to
non-SCA clients.
Yes but the semantics are different and that's one of the reasons I
don't like it much (it is going to confuse end-users). A
locateService from non-mamanged code will not return a chain with
source-side policy (which would be expected, since it is not a
component). The problem really shows up in the following situation:
1. A client component has a transactional policy associated with it
that propagates
2. The target requires a client call it with the transactional policy
3. The client does this:
public class Foo {
@Context CurrentCompositeContext context;
public void operation() {
context.locateService(Foo.class, Foo).doSomething();
}
}
It works.
4. The client instead does this and they get some kind of trx context
error because now it is behaving as unmanaged code:
public class Foo {
public void operation() {
CurrentCompositeContext.getContext().locateService(Foo.class,
Foo).doSomething();
}
}
In the spec group, we played around with the notion of a default
context which would get around this problem. A better solution may be
to eliminate locate service for components (e.g. @Context) altogether
and only relying on dependency injection (this would involve making a
war or jsp a component impl type). The only case where I see a
problem with this is in a completely dynamic situation where the
component name is passed in (in which case only the interface is
known). This may be something we can do through autowire or through
multiplicity references. Can you describe the use-case a little more?
Jim
On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote:
This I think highlights a problem with the spec around using
CurrentCompositeContext from unmamanged code in general...a locate
service only returns half of an invocation chain since the source
is not a component and is unmamanged code. Can you describe you
client code, is it a JSP or is it from a component?
Jim
On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote:
I've tried out the suggested fixes and I have run into a big
problem.
By proxying the inbound wire of the composite reference, there
is no
databinding interceptor in the invocation chain. This causes
Axis2TargetInvoker to choke.
Exception java.lang.IllegalArgumentException Exception
message: Can't
handle mixed payloads betweem OMElements and other types.
java.lang.IllegalArgumentException: Can't handle mixed payloads
betweem
OMElements and other types.
at
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCl
i
ent
(Axis2TargetInvoker.java)
at
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(
Axis2TargetInvoker.java:70)
at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(
Axis2TargetInvoker.java:107)
at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(
InvokerInterceptor.java:44)
at
org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(
SynchronousBridgingInterceptor.java:41)
at
org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(
AbstractInboundInvocationHandler.java:60)
at
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(
JDKInboundInvocationHandler.java:108)
How do we get the databinding transformation into this flow? The
DatabindingInterceptor currently requires an outbound wire from the
client.
Dynamically creating an outbound wire for a non-SCA client and
connecting it
to the composite reference sounds like a major piece of work. Is
there a
simpler solution?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-956) SDOFactory instance lookup is using the wrong namespace URI
[ http://issues.apache.org/jira/browse/TUSCANY-956?page=all ] Kelvin Goodson resolved TUSCANY-956. Fix Version/s: Java-Mx Resolution: Fixed Patch committed at level 481007 SDOFactory instance lookup is using the wrong namespace URI --- Key: TUSCANY-956 URL: http://issues.apache.org/jira/browse/TUSCANY-956 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-Mx Reporter: Fuhwei Lwo Fix For: Java-Mx Attachments: tuscany-956.patch String eNS_URI = http://www.apache.org/tuscany/2005/SDO;; in SDOPackage.java was defined to represent Tuscany SDO package but in the SDOFactoryImpl.java it uses http://www.eclipse.org/emf/2003/SDO; to look up the registered SDOFactory instance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Binding/Language Extensions - packaging
On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Andrew Borley [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Simon Laws [EMAIL PROTECTED] wrote: On 11/30/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: On 30/11/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Pete Robbins wrote: Our current method of packaging and loading an extension is fairly simple: we load all schema and libraries in the extensions path. This has a number of problems. 1. An extension may consist of more than one library e.g . libmy_extension.so and libmy_extension_utils.so. Our current loading scheme will attempt to load both of these and may fail on the one that doesn't provide the extension initialize method. On MacOS the output of our build produces a libx.dylib and a series of symlinks to this called libx.0.dylib, libx.0.0.dylib etc.. ur runtime loads ALL of these which doesn't cause problems as they are all the sam library and just repeatedly register to handle the same requests. Very inefficient though! 2. Control of whether or not to load an extension library is currently by renaming the library so the runtime doesn't find it. An example is that we ship our python extension as libtuscany_sca_python.so.diabled. This is horrible and error prone. We could improve this by having a system configuration file that lists the required extensions but the I like the self contained package approach that we have now. I'd like to implement an improved scheme for packaging an extension by introducing a per extension configuration file. Something like: tuscany_sca_ws_binding.extension scacpp:extension name=ws binding enabled=true library name=tuscany_sca_ws_reference/ library name=tuscany_sca_ws_service/ /scacppp:extension So the package would look like: extensions/ ws/ tusany_sca_ws_binding.extension lib/ xsd/ other_folder/ ... The .extension configuration file is saying to load the library which is located somewhere in the package... the runtime will find it... no need to specify a path. Taking this further the configuration file could list the schema to be loaded. Currently the runtime will just load any it finds but these may not be needed by the runtime e.g. the schema may be for some extension implementation specific purpose. I think it would also be good for the extension initialization() method to take as a parameter the root of the extension e.g. extension(/tuscany/extensions/ws). This would allow the extension package to contain any configuration information that it needs. I'd like to start by at least introducing the .extension file for each extension and loading only the specified library(ies) if the extension is enabled. Any thoughts? Two thoughts: - convention over configuration - the runtime should be consumable without having
Re: Proposal for a (Java) community test suite for SDO
On 11/30/06, Dan Murphy [EMAIL PROTECTED] wrote: I would like to propose starting a community test suite for service data objects (SDO CTS) implementations written in Java. Based on feedback from an earlier post this seems to be the first logical step in getting interoperable SDO implementations in all languages. I can see this leading to an interoperability test suite to check serialisation between implementations also works (across languages and implementations). Proposal for Community Test Suite (CTS) for SDO Develop a test suite to validate an SDO implementation behaves as expected, according to the community's understanding of the SDO specification. Should the specification appear ambiguous or unclear then the community will decide what to do; it may decide to test the area with an agreed expected behaviour, or decide not to test this area. Ambiguities will be fed back to the specification group for clarification. Although we will run this against Tuscany, the test suite will only test things that we think any implementation should support. The SDO CTS will enable developers to choose or switch SDO implementations without the concern of having to re-code a significant proportion of their application due to differences between implementations. This community test suite will first focus on areas identified important to developers of SDO applications. SDO users feedback and involvement will be crucial to the success of this effort. Over time this may grow to include a large proportion of the SDO specification, however the suite should grow according to the community's desire, rather than attempting to be a validation or compliancy suite. To encourage everyone with an interest in SDO to contribute and use the suite, I propose we : 1. Create a separate module in SVN to separate this from Tuscany components and testcases. 2. Make use of a java package namespace that is not attributable to either Tuscany or any other SDO implementation: test.sdo 3. Refactor some of the existing Tuscany SDO Java test cases to remove any Tuscany specific coding and re-package these to the test.sdo namespace. 4. Accept tests from anyone who wishes to contribute them under normal Apache contribution conditions. SDO users involvement will be crucial to this effort, developers of SDO implementations will benefit by contributing to and consuming a community test suite, rather than working on their own. Who's up for working on this with me ? If you are interested in joining this effort; have any concerns, comments or suggestions please append them... Thanks in advance to all those who volunteer :) Dan Hi Dan a community test suite for service data objects (SDO CTS) implementations written in Java. I can see why you need to a test suite the test Java implementations but do you believe that some of this work will be useful to other language implementations also. We've talked before about the interop schemas up on SVN in the interop directory. If, for example, in your new effort the community decided that it would be a nice idea to test that SDO load and saves XML files based on schema that reflect the mappings defined in the specs (something I would imagine that you would be interested in) then it would be good if you can take what we have and enhance or replace them. This would then be useful in a context wider than Java because we use these tests in C++ and PHP SDO also. If you were able to make improvements here that would be work we wouldn't have to duplicate. Are there any other SDO tests that you think we could collaborate on cross langauge? For example, clearly API tests would be difficult :-) but how about serialisation of data objects trees and/or change summaries? Regards Simon
Maven running in Tomcat?
Hi Folks, When I deploy a Tuscany sample to Tomcat, I see what looks like Maven trying to update its repository. Is there a way to disable this behavior? (Something akin to maven's '-o' command-line option maybe...) Thanks, -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test case fails: LoanAppConversationTestCase
Also not seeing this issue. The junit test works for me in eclipse too. svn rev 480786 Sun jdk java full version 1.5.0_10-b03 Raymond Feng wrote: Hi, I'm seeing the following test case failure in trunk code. Raymond --- T E S T S --- Running loanappconversation.LoanAppConversationTestCase Applied: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, s tatus: open Loan approved: false Sleeping to let cancel complete ... Cancelled: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, status: cancelled Trying to use the closed loan in the ended conversation ... Closed: Loan application: null, term: 0, status: closed junit.framework.AssertionFailedError: Target should not be found at junit.framework.Assert.fail(Assert.java:47) at loanappconversation.LoanAppConversationTestCase.test(LoanAppConversat ionTestCase.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:269) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:788) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.375 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test case fails: LoanAppConversationTestCase
It's a bit wierd. Now it works for me as well. Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, November 30, 2006 10:10 AM Subject: Re: Test case fails: LoanAppConversationTestCase Also not seeing this issue. The junit test works for me in eclipse too. svn rev 480786 Sun jdk java full version 1.5.0_10-b03 Raymond Feng wrote: Hi, I'm seeing the following test case failure in trunk code. Raymond --- T E S T S --- Running loanappconversation.LoanAppConversationTestCase Applied: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, s tatus: open Loan approved: false Sleeping to let cancel complete ... Cancelled: Loan application: [Customer: John Doe, loan amount: 1000.0], term: 0, status: cancelled Trying to use the closed loan in the ended conversation ... Closed: Loan application: null, term: 0, status: closed junit.framework.AssertionFailedError: Target should not be found at junit.framework.Assert.fail(Assert.java:47) at loanappconversation.LoanAppConversationTestCase.test(LoanAppConversat ionTestCase.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:269) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:788) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.375 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 - 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: Maven running in Tomcat?
There is a context parameter tuscany.online which defaults to true - if you set this to false in webapp.xml then it should disable this behaviour. -- Jeremy On 11/30/06, Matthew Duftler [EMAIL PROTECTED] wrote: Hi Folks, When I deploy a Tuscany sample to Tomcat, I see what looks like Maven trying to update its repository. Is there a way to disable this behavior? (Something akin to maven's '-o' command-line option maybe...) Thanks, -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-959) Please use thread-safe libraries
Please use thread-safe libraries Key: TUSCANY-959 URL: http://issues.apache.org/jira/browse/TUSCANY-959 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor One of our SDO for PHP users is planning to run in a multi-threaded web server. They have run an evaluation tool and only found one thread-safety issue - the use of localtime() rather than localtime_r() in commonj/sdo/SDODate.cpp. Please would you modify this call accordingly? It's fine for this to be a conditional compile if you prefer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Thread safety ?
This is now http://issues.apache.org/jira/browse/TUSCANY-959
[jira] Created: (TUSCANY-960) Spurious xsi:type=OpenDataObject attribute generated
Spurious xsi:type=OpenDataObject attribute generated -- Key: TUSCANY-960 URL: http://issues.apache.org/jira/browse/TUSCANY-960 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Reporter: Caroline Maynard Priority: Minor I have a schema where a property has an open data type. I read in an XML document: content type=xhtml xml:lang=en xml:base=http://diveintomark.org/; div xmlns=http://www.w3.org/1999/xhtml; p i[Update: The Atom draft is finished.]/i /p div class=myclass pHello/p /div /div /content then I convert it back to a string, and it looks like this: content type=xhtml lang=en base=http://diveintomark.org/;langen/langbasehttp://diveintomark.org//base div xsi:type=OpenDataObject p xsi:type=OpenDataObject i xsi:type=OpenDataObject[Update: The Atom draft is finished.]/i /p div xsi:type=OpenDataObject class=myclassclassmyclass/class p xsi:type=OpenDataObjectHello/p /div /div /content The type attributes add no value and make the output cluttered and confusing. Please eliminate them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Is Type::OpenDataObjectType part of the API?
On 30/11/06, Pete Robbins [EMAIL PROTECTED] wrote: Ah a test!! Would it be that classs is serialized as both an attribute and an element?? Indeed. Not only class, but xml:base and xml:lang, too. I've opened http://issues.apache.org/jira/browse/TUSCANY-960 for the xsi:type=OpenDataObject issue. -- Caroline
Proposal for a (Java) community test suite for SDO
I would like to propose starting a community test suite for service data objects (SDO CTS) implementations written in Java. Based on feedback from an earlier post this seems to be the first logical step in getting interoperable SDO implementations in all languages. I can see this leading to an interoperability test suite to check serialisation between implementations also works (across languages and implementations). Proposal for Community Test Suite (CTS) for SDO Develop a test suite to validate an SDO implementation behaves as expected, according to the community's understanding of the SDO specification. Should the specification appear ambiguous or unclear then the community will decide what to do; it may decide to test the area with an agreed expected behaviour, or decide not to test this area. Ambiguities will be fed back to the specification group for clarification. Although we will run this against Tuscany, the test suite will only test things that we think any implementation should support. The SDO CTS will enable developers to choose or switch SDO implementations without the concern of having to re-code a significant proportion of their application due to differences between implementations. This community test suite will first focus on areas identified important to developers of SDO applications. SDO users feedback and involvement will be crucial to the success of this effort. Over time this may grow to include a large proportion of the SDO specification, however the suite should grow according to the community's desire, rather than attempting to be a validation or compliancy suite. To encourage everyone with an interest in SDO to contribute and use the suite, I propose we : 1. Create a separate module in SVN to separate this from Tuscany components and testcases. 2. Make use of a java package namespace that is not attributable to either Tuscany or any other SDO implementation: test.sdo 3. Refactor some of the existing Tuscany SDO Java test cases to remove any Tuscany specific coding and re-package these to the test.sdo namespace. 4. Accept tests from anyone who wishes to contribute them under normal Apache contribution conditions. SDO users involvement will be crucial to this effort, developers of SDO implementations will benefit by contributing to and consuming a community test suite, rather than working on their own. Who's up for working on this with me ? If you are interested in joining this effort; have any concerns, comments or suggestions please append them... Thanks in advance to all those who volunteer :) Dan
NPE was Re: [jira] Resolved: (TUSCANY-951) NullPointerException when setting an invalid property
Kelvin, My feeling is that runtime code should never throw a NullPointerException. In this particular case where it is very easy for users to input an invalid string value because of typos, case sensitivity, or just not remembering the correct property name, it is pretty ugly. If there is no spec behavior defined for what happens in the case of an invalid set, then the SDO runtime should probably use its former behavior of throwing an IllegalArgumentException. Brent On 11/30/06, Kelvin Goodson (JIRA) tuscany-dev@ws.apache.org wrote: [ http://issues.apache.org/jira/browse/TUSCANY-951?page=all ] Kelvin Goodson resolved TUSCANY-951. Fix Version/s: Java-M2 Java-Mx Resolution: Duplicate This is an instance of the issue in TUSCANY-578. In this case its the variant of the issue where the spec isn't specific about the type of exception should be thrown, and the changes made under TUSCANY-885 have altered the behaviour of the tuscany implementation without violating the spec. I'm going to transfer this into the TUSCANY-885 bucket defect for consideration, but my feeling is that this is not a bug. NullPointerException when setting an invalid property - Key: TUSCANY-951 URL: http://issues.apache.org/jira/browse/TUSCANY-951 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Brent Daniel Fix For: Java-M2, Java-Mx Calling set() with an invalid property name results in a NullPointerException. For example: dataObject.setInt(invalidProperty, 5); results in: java.lang.NullPointerException at org.apache.tuscany.sdo.util.DataObjectUtil.getSetValue(DataObjectUtil.java:1440) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:537) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:526) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
Jim,
See below please.
-Dave
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, November 30, 2006 12:44 PM
Subject: Re: Creating proxies (fix for TUSCANY-862)
On Nov 30, 2006, at 9:21 AM, Greg Dritschler wrote:
I've been using a JSP to test this. At this point I'm not sure how much
restricting the client to an SCA component helps because the
locateService
is still dynamic. Anyway the spec says locateService is available to
non-SCA clients.
Yes but the semantics are different and that's one of the reasons I don't
like it much (it is going to confuse end-users). A locateService from
non-mamanged code will not return a chain with source-side policy (which
would be expected, since it is not a component). The problem really shows
up in the following situation:
1. A client component has a transactional policy associated with it that
propagates
2. The target requires a client call it with the transactional policy
3. The client does this:
public class Foo {
@Context CurrentCompositeContext context;
public void operation() {
context.locateService(Foo.class, Foo).doSomething();
}
}
It works.
4. The client instead does this and they get some kind of trx context
error because now it is behaving as unmanaged code:
public class Foo {
public void operation() {
CurrentCompositeContext.getContext().locateService(Foo.class,
Foo).doSomething();
}
}
WRT transactions, the specs will never support a case where a service
provider requires that a client propogate a transaction. Perhaps it's just
that your example is bad.
The spec doesn't talk about source side chains, so this is clearly an
implementation issue. If a composite reference contains decorations for
policy (intents or policySets), then it is the reference binding's
responsibility to act on those policy decorations. If it cannot do so, it
must throw an error. Managed vs. un-managed environments can certainly
create differences in policy behavior. I still don't see what that has to
do with the ability of the locateService API to provide a proxy for a
configured composite reference. Having source side policy configured on a
composite reference is related to the presence of source side policy on the
reference, and has nothing to do with an particular component.
In the spec group, we played around with the notion of a default
context which would get around this problem. A better solution may be to
eliminate locate service for components (e.g. @Context) altogether and
only relying on dependency injection (this would involve making a war or
jsp a component impl type). The only case where I see a problem with this
is in a completely dynamic situation where the component name is passed
in (in which case only the interface is known). This may be something we
can do through autowire or through multiplicity references. Can you
describe the use-case a little more?
The use case is very simple. A composite level reference with a WSDL
interface type. The locateService() API should be able to return a proxy to
that reference. The locateService API might be invoked from with an SCA
component implementation, or not. As I recall, this is a use case that you
pushed into the spec.
Jim
On 11/30/06, Jim Marino [EMAIL PROTECTED] wrote:
This I think highlights a problem with the spec around using
CurrentCompositeContext from unmamanged code in general...a locate
service only returns half of an invocation chain since the source
is not a component and is unmamanged code. Can you describe you
client code, is it a JSP or is it from a component?
Jim
On Nov 30, 2006, at 6:51 AM, Greg Dritschler wrote:
I've tried out the suggested fixes and I have run into a big
problem.
By proxying the inbound wire of the composite reference, there
is no
databinding interceptor in the invocation chain. This causes
Axis2TargetInvoker to choke.
Exception java.lang.IllegalArgumentException Exception
message: Can't
handle mixed payloads betweem OMElements and other types.
java.lang.IllegalArgumentException: Can't handle mixed payloads
betweem
OMElements and other types.
at
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.createOperationCl i
ent
(Axis2TargetInvoker.java)
at
org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(
Axis2TargetInvoker.java:70)
at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(
Axis2TargetInvoker.java:107)
at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(
InvokerInterceptor.java:44)
at
org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(
SynchronousBridgingInterceptor.java:41)
at
org.apache.tuscany.spi.wire.AbstractInboundInvocationHandler.invoke(
AbstractInboundInvocationHandler.java:60)
at
org.apache.tuscany.core.wire.jdk.JDKInboundInvocationHandler.invoke(
JDKInboundInvocationHandler.java:108)
How do we get the databinding transformation
Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release)
Hi, This is an appealing proposal. I will give a try. Thanks, Raymond - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, November 30, 2006 5:48 AM Subject: Re: Much ado about nothing (Re: WSCOMMONS-131 and options for Tuscany SCA Java M2 release) Folks, Can't you just use maven's exclusion mechanism: http://maven.apache.org/ref/2.0.4/maven-model/maven.html#class_exclusion to exclude the specific version of axiom and add a specific dependency on the new one? thanks, dims On 11/29/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Aha! so there's a catch. We still haven't started the process for a Axis2 1.1.1. Hoping to do that with a thorough JIRA scrub this week or early next week. To see what needs to be fixed for a quick 1.1.1 release. Will let you all know when we have some idea. thanks, dims On 11/29/06, Simon Nash [EMAIL PROTECTED] wrote: Thanks, Dims. We will need a new release of Axis2 as well, since the POMs in Axis2 1.1 point to Axiom 1.2. Will this be available at the same time as the new release of Axiom? Simon Davanum Srinivas wrote: Thanks Jim/Jeremy :) Please look at the pom's in the svn. the SNAPSHOT jars are here: http://ws.zones.apache.org/repository/org.apache.ws.commons.axiom/jars/ thanks, dims On 11/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Nov 28, 2006, at 1:24 PM, Davanum Srinivas wrote: Folks, Fact #1: WSCOMMONS-131 is fixed in SVN. Fact #2: We've started a VOTE for releasing Axiom 1.2.1 [1]. Plan is to do the release this week. What's the ruckus all about? (Please don't make me all the emails :) Well, now, nothing :-) Are there any artifacts for 1.2.1 that we can take a look at? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: http://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
[ http://issues.apache.org/jira/browse/TUSCANY-961?page=all ] Brent Daniel reassigned TUSCANY-961: Assignee: Brent Daniel DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: http://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating proxies (fix for TUSCANY-862)
On Nov 30, 2006, at 1:06 PM, scabooz wrote:
Jim,
See below please.
-Dave
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, November 30, 2006 12:44 PM
Subject: Re: Creating proxies (fix for TUSCANY-862)
On Nov 30, 2006, at 9:21 AM, Greg Dritschler wrote:
I've been using a JSP to test this. At this point I'm not sure
how much
restricting the client to an SCA component helps because the
locateService
is still dynamic. Anyway the spec says locateService is
available to
non-SCA clients.
Yes but the semantics are different and that's one of the reasons
I don't like it much (it is going to confuse end-users). A
locateService from non-mamanged code will not return a chain with
source-side policy (which would be expected, since it is not a
component). The problem really shows up in the following situation:
1. A client component has a transactional policy associated with
it that propagates
2. The target requires a client call it with the transactional policy
3. The client does this:
public class Foo {
@Context CurrentCompositeContext context;
public void operation() {
context.locateService(Foo.class, Foo).doSomething();
}
}
It works.
4. The client instead does this and they get some kind of trx
context error because now it is behaving as unmanaged code:
public class Foo {
public void operation() {
CurrentCompositeContext.getContext().locateService(Foo.class,
Foo).doSomething();
}
}
WRT transactions, the specs will never support a case where a
service provider requires that a client propogate a transaction.
How about between two local services where the target requires a
transaction to be active? By propagation I don't mean remote
boundaries.
Perhaps it's just that your example is bad.
The spec doesn't talk about source side chains, so this is clearly
an implementation issue.
Yes that is correct.
If a composite reference contains decorations for policy (intents
or policySets), then it is the reference binding's responsibility
to act on those policy decorations. If it cannot do so, it must
throw an error. Managed vs. un-managed environments can certainly
create differences in policy behavior.
That was what I was getting at and I think overloading locateService
(it behaves differently if it is done from a ComponentContext that is
obtained through injection with @Context or getCurrentContext()) is
going to be confusing.
I still don't see what that has to do with the ability of the
locateService API to provide a proxy for a configured composite
reference.
It doesn't. It has more to do with the overloading issue above.
Having source side policy configured on a composite reference is
related to the presence of source side policy on the reference, and
has nothing to do with an particular component.
If this is the case, then we have different behavior in the following
case, which is equally confusing:
public class ComponentImpl {
@Context
protected CurrentCompositeContext context;
@Reference // wired to FooService in the scdl
protected Foo foo;
public someOperation() {
context.locateService(Foo.class FooService).invoke();
CurrentCompositeContext.getContext().locateService(Foo.class
FooService).invoke(); // is different from above
}
In the spec group, we played around with the notion of a default
context which would get around this problem. A better solution may
be to eliminate locate service for components (e.g. @Context)
altogether and only relying on dependency injection (this would
involve making a war or jsp a component impl type). The only case
where I see a problem with this is in a completely dynamic
situation where the component name is passed in (in which case
only the interface is known). This may be something we can do
through autowire or through multiplicity references. Can you
describe the use-case a little more?
The use case is very simple. A composite level reference with a
WSDL interface type. The locateService() API should be able to
return a proxy to that reference. The locateService API might be
invoked from with an SCA component implementation, or not. As I
recall, this is a use case that you pushed into the spec.
Whether locateService() should return a proxy or not is a separate
issue (it really has to). I was questioning:
1. The utility of even having the option of locateService from within
a component. I don't think it is needed. The only case I can see for
this is dynamic service lookups but I believe that can be solved by
multiplicity as the service contract is known upfront by the client
(just wire a multiplicity at assembly/deployment).
2. Whether it is possible to eliminate the concept of unmanaged code
altogether. I think we could do this from JSPs by modeling a war file
as a
[jira] Commented: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec
[ http://issues.apache.org/jira/browse/TUSCANY-578?page=comments#action_12454761 ] Yang ZHONG commented on TUSCANY-578: Having discussed with Frank, will fix this along within 935 Exceptions thrown by SDO runtime not the same as defined in the spec Key: TUSCANY-578 URL: http://issues.apache.org/jira/browse/TUSCANY-578 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Reporter: Brian Murray Priority: Minor Fix For: Java-Mx Attachments: DataObjectUtil.patch On page 27 of V2.01 of the spec, specific exceptions are listed for certain kinds of errors. In some cases, a different exception is thrown (each case will be added as a subtask). Either the specification or the implementation should be updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-951) NullPointerException when setting an invalid property
[ http://issues.apache.org/jira/browse/TUSCANY-951?page=comments#action_12454763 ] Yang ZHONG commented on TUSCANY-951: Having discussed with Frank, will fix this along within 935 NullPointerException when setting an invalid property - Key: TUSCANY-951 URL: http://issues.apache.org/jira/browse/TUSCANY-951 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Brent Daniel Fix For: Java-Mx, Java-M2 Calling set() with an invalid property name results in a NullPointerException. For example: dataObject.setInt(invalidProperty, 5); results in: java.lang.NullPointerException at org.apache.tuscany.sdo.util.DataObjectUtil.getSetValue(DataObjectUtil.java:1440) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:537) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:526) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-949) Incorrect set of extensions published to the maven repo
I feel that M2 should have been (is) in lock down and fixes should only be to issues that clearly break functionality. However, we the community SHOULD have stuck to that position. Given we gave the go ahead to this and two people have claimed to have tested it and it addresses the issue stated I think we should accept it. ant elder wrote: On 11/29/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Nov 29, 2006, at 4:00 AM, ant elder wrote: Looks like that answers all the questions and sounds convincing to me. We discussed doing this the other day and agreed it needed doing and based on that Simon went ahead and did the work for it, so I think we should go ahead and apply this to M2 now. Unless there are any other concerns I'll do this tonight. We didn't agree it needed doing. I still don't think it does as I see no downside to not making this change. I have concerns that using profiles this way will cause problems (e.g. what happens if two profiles include different modules) and I was hoping Simon had a better solution. I think this approach is confusing for users as it's not obvious which modules get built and which don't. I am also concerned that there has not been enough testing given we are so close to release. I'm not concerned enough though to veto such a change so if you think it's the right thing to do then go ahead. I would suggest waiting to see what the consensus really is. -- Jeremy I'm reluctant to commit this while you're so against it, but I'm not sure I understand your concerns. We did clearly tell Simon to go and make a patch to do this: jboynes simonnash: if you want something different, please give us a patch for the build to build it as YOU want it and: simonnash so in building the release I would expect to select a subset of all available modules and copy those selected modules into contrib and also deploy htem to maven jboynes patches welcome simonnash ok i will do what I can. any help from others will be appreciated. and then the IRC chat summary posted to the dev list clearly said it was happening: there was some discussion around what Tuscany jars are released as part of M2 into the maven repository. Currently everything in the Tuscany build is released, should that be trimmed to only those things that we want to say are ready? Simon is going to create a patch to the build to make this possible. No one questioned that and in good faith he's gone off and made a patch as requested. With the current Axiom issue we have a bit of time now, I've tried the patch and seems to work fine, would you give it a test? What other testing would you like to see? Another thing I think we should remember is that this patch is from a new contributor so we should be receptive so as to encourage further participation. I'd really appreciate others comments on if we should apply this. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-97) Read only properties
[ http://issues.apache.org/jira/browse/TUSCANY-97?page=all ] Yang ZHONG updated TUSCANY-97: -- Attachment: EnforceReadOnly.97 The attachment is requested for public review. Thanks. Read only properties Key: TUSCANY-97 URL: http://issues.apache.org/jira/browse/TUSCANY-97 Project: Tuscany Issue Type: Task Components: C++ SDO Affects Versions: Cpp-current Reporter: Ed Slattery Priority: Trivial Fix For: Cpp-current Attachments: EnforceReadOnly.97 Read-only properties are not fully supported, and should be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO C++] Thread safety ?
Caroline Maynard wrote: On 21/11/06, Geoffrey Winn [EMAIL PROTECTED] wrote: As far as SDO itself is concerned, I think we would be OK if the user of SDO could guarantee that whenever an SDO artifact (data factory, data object, type, XSDHelper ...) is created then that artifact will be used _exclusively_ by the thread that created it. If that's acceptable to you then I'll check the code to ensure that my claim is correct. Yes, that's how it would be. The SDO for PHP implementation doesn't keep references to Tuscany objects in static data. As you observed earlier we will need to resolve the localtime issue. I'll raise a JIRA for that. Outside of SDO we will also need to check the various libraries that we depend on. You mentioned libxml2 but there is also zlib and iconv too. Based on a quick look at the libxml2 reference that you supplied we wll need a small change to the SDO build process but also possibly some code changes too. Both zlib and iconv are also part of the normal PHP environment, because libxml2 depends on them, so I don't expect issues with them. But FYI, zlib has a faq: http://www.zlib.net/zlib_faq.html#faq21 As for iconv, I think that libxml2 will use whatever iconv implementation it finds on the platform, which is not necessarily libiconv, so a general statement may not be possible. Do you think that we should build with the thread safe libs by default? or have 2 bin libraries one thread safe, one not but faster? The question applies to both Linux and Windows, and I'm not sure but we may have different answers for different systems. Caroline, maybe I missed it in the email thread, but do your users need this on Linux? Windows? both? Thanks, -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
