[jira] Closed: (TUSCANY-72) Improve handling of Axis exceptions
[ http://issues.apache.org/jira/browse/TUSCANY-72?page=all ] Pete Robbins closed TUSCANY-72: --- Resolution: Incomplete Assign To: Pete Robbins Closed as this was for Axis 1.x Improve handling of Axis exceptions --- Key: TUSCANY-72 URL: http://issues.apache.org/jira/browse/TUSCANY-72 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Axis exceptions should be caught and handled to give better feedback on the causes of problems -- 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-89) Provide Axis2C bindings
[ http://issues.apache.org/jira/browse/TUSCANY-89?page=all ] Pete Robbins resolved TUSCANY-89: - Resolution: Fixed Resolving this and opening new Jiras for remaining issues. Provide Axis2C bindings --- Key: TUSCANY-89 URL: http://issues.apache.org/jira/browse/TUSCANY-89 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Provide support for Axis2 ws bindings using Axis2C -- 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] Closed: (TUSCANY-89) Provide Axis2C bindings
[ http://issues.apache.org/jira/browse/TUSCANY-89?page=all ] Pete Robbins closed TUSCANY-89: --- Provide Axis2C bindings --- Key: TUSCANY-89 URL: http://issues.apache.org/jira/browse/TUSCANY-89 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Provide support for Axis2 ws bindings using Axis2C -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-429) WS EntryPoiny binding for Axis2C
WS EntryPoiny binding for Axis2C Key: TUSCANY-429 URL: http://issues.apache.org/jira/browse/TUSCANY-429 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Provide capability to expose SCA entry point as Axis2c service -- 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-429) WS EntryPoiny binding for Axis2C
[ http://issues.apache.org/jira/browse/TUSCANY-429?page=all ] Pete Robbins reassigned TUSCANY-429: Assign To: Pete Robbins WS EntryPoiny binding for Axis2C Key: TUSCANY-429 URL: http://issues.apache.org/jira/browse/TUSCANY-429 Project: Tuscany Type: New Feature Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current Provide capability to expose SCA entry point as Axis2c service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-430) Support RPC for WS External Service
Support RPC for WS External Service --- Key: TUSCANY-430 URL: http://issues.apache.org/jira/browse/TUSCANY-430 Project: Tuscany Type: Improvement Components: C++ SCA Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current Current code only supports Doc-Lit WS -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-431) XSDHelper does not always create a DataFactory
XSDHelper does not always create a DataFactory -- Key: TUSCANY-431 URL: http://issues.apache.org/jira/browse/TUSCANY-431 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current It is possible to construct an XSDHelper which does not contain a DataFactory. -- 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-431) XSDHelper does not always create a DataFactory
[ http://issues.apache.org/jira/browse/TUSCANY-431?page=comments#action_12413442 ] Pete Robbins commented on TUSCANY-431: -- XSDHelperPtr xh = HelperProvider::getXSDHelper(); DataFactoryPtr df = xh.getDataFactory(); // --- returns NULL XSDHelper::generate() etc methods wil also fail unless a define() method is called first. XSDHelper does not always create a DataFactory -- Key: TUSCANY-431 URL: http://issues.apache.org/jira/browse/TUSCANY-431 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Reporter: Pete Robbins Fix For: Cpp-current It is possible to construct an XSDHelper which does not contain a DataFactory. -- 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-417) Interactive JavaScript SCA client
[ http://issues.apache.org/jira/browse/TUSCANY-417?page=comments#action_12413444 ] ant elder commented on TUSCANY-417: --- Thanks for the patch Jojo, I've commit it, with the changes we discussed on IM, into the contianer.rhino project in pkg: org/apache/tuscany/container/rhino/shell/ Great stuff, i'm looking forward to the addition of more functionality you talk about. Here's some things i can think of right now that would be useful, i'm sure theres others: - being able to pass in the loadModule to use as a parameter on startup, eg, java -cp... org.apache.tuscany.container.rhino.shell.TuscanyShell sample-helloworld-incubating-M1.jar - having it work with war files (including the lib and classes dir within) like sample-helloworldws-incubating-M1.war - automatically registering the components in the module so you don't need to do explicit getComponent calls (see unfinished discussion on the mailing list) Interactive JavaScript SCA client - Key: TUSCANY-417 URL: http://issues.apache.org/jira/browse/TUSCANY-417 Project: Tuscany Type: New Feature Components: Java SCA JavaScript Container Versions: Java-M2 Reporter: ant elder Assignee: ant elder Fix For: Java-M2 Attachments: TuscanyShell.zip Create a new JavaScript SCA client shell similar to the Rhino shell -- 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-431) XSDHelper does not always create a DataFactory
[ http://issues.apache.org/jira/browse/TUSCANY-431?page=all ] Pete Robbins reassigned TUSCANY-431: Assign To: Pete Robbins XSDHelper does not always create a DataFactory -- Key: TUSCANY-431 URL: http://issues.apache.org/jira/browse/TUSCANY-431 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current It is possible to construct an XSDHelper which does not contain a DataFactory. -- 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-431) XSDHelper does not always create a DataFactory
[ http://issues.apache.org/jira/browse/TUSCANY-431?page=all ] Pete Robbins resolved TUSCANY-431: -- Resolution: Fixed The same problem occured in XMLHelper XSDHelper does not always create a DataFactory -- Key: TUSCANY-431 URL: http://issues.apache.org/jira/browse/TUSCANY-431 Project: Tuscany Type: Bug Components: C++ SDO Versions: Cpp-current Reporter: Pete Robbins Assignee: Pete Robbins Fix For: Cpp-current It is possible to construct an XSDHelper which does not contain a DataFactory. -- 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]
New interactive SCA client
As part of TUSCANY-417 I've committed a patch from Jojo for the start of an interactive client using JavaScript. I think its quite cool. You can start it up like this: C:\Tuscany\SCA\distribution\target\tuscany-distjava -cp lib\tuscany- runtime-incubating-M1.jar org.apache.tuscany.container.rhino.shell.TuscanyShell Tuscany SCA Shell 0.1, type help() for a list of supported functions. js Then at the js prompt you can enter commands and JavaScript statements and have them executed interactively. You can invoke SCA components by loading the module and getting the component, for example: js loadModule(samples/sca/helloworld/target/sample- helloworld-incubating-M1.jar); js var hw = getComponent(HelloWorldServiceComponent) js hw.getGreetings(petra) Hello petra js Its still a bit primitive, but this is interesting and we plan to make it much more user friendly and powerful. Check it out and give us feedback. ...ant
Re: Getting list of components in a module
Never did get any answer on this. Having the class below in the rhino
container works as it uses the AbstractCompositeContext package name, but it
seesm a bit hacky:
package org.apache.tuscany.core.context.impl;
public class ComponentNamesAccessor {
public static SetString getComponentNames(ModuleContext moduleContext)
{
if (moduleContext instanceof AbstractCompositeContext) {
MapString, ScopeContext x = ((AbstractCompositeContext)
moduleContext).scopeIndex;
return x.keySet();
}
return null;
}
}
...ant
On 5/24/06, ant elder [EMAIL PROTECTED] wrote:
Jim, this would be unmanaged code, not in a component, so it doesn't look
like there is any API for this. The idea of TUSCANY-417 is an interactive
JavaScript shell along the lines of what Jeremy described as a first-class
client environment for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've a J2SE client that needs to get a list of all the components
defined in
the current module, is that possible? There used to be the getMetaData
method but thats been removed now. If there is no easy way right
now could
i add something?
...ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ Release
+1 for the release, but i can't make an IRC chat on Tuesday sorry. ...ant On 5/25/06, Pete Robbins [EMAIL PROTECTED] wrote: As mentioned previously we would be a like to have a binary release of the C++ code by ApacheCon Europe. I'd like to propose an IRC chat on Tuesday 6th June 17:00 BST (18:00 GMT) 12:00 (Eastern) 09:00 (Pacific) to finalize content and schedule to achieve this. As a starting point, and for discussion until then, there is a wiki page, http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks. I will be unavailable from 28th May - June 5th but I'd hope that there will be some discussion on this thread before I get back. Cheers, -- Pete
Re: C++ Release
Pete +1 for release and IRC chat On 5/25/06, Pete Robbins [EMAIL PROTECTED] wrote: As mentioned previously we would be a like to have a binary release of the C++ code by ApacheCon Europe. I'd like to propose an IRC chat on Tuesday 6th June 17:00 BST (18:00 GMT) 12:00 (Eastern) 09:00 (Pacific) to finalize content and schedule to achieve this. As a starting point, and for discussion until then, there is a wiki page, http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks. I will be unavailable from 28th May - June 5th but I'd hope that there will be some discussion on this thread before I get back. Cheers, -- Pete
CANCELED - Tuscany weekly IRC Chat on Monday, May 29
Canceled due to public holidays in various places around the world. ...ant
Re: C++ Release
Pete, another +1 for the release and IRC chat
[PATCH] A patch for the sandbox container.spring code
The patch added support toresolve Resource
from contextLocation.
Index: java/org/apache/tuscany/container/spring/SCABeanDefinitionReader.java
===
--- java/org/apache/tuscany/container/spring/SCABeanDefinitionReader.java
(revision 409683)
+++ java/org/apache/tuscany/container/spring/SCABeanDefinitionReader.java
(working copy)
@@ -19,7 +19,7 @@
protected XmlBeanDefinitionParser createXmlBeanDefinitionParser() {
-return new SCAXmlBeanDefinitionParser(componentType);
+return new SCAXMLBeanDefinitionParser(componentType);
}
}
Index: java/org/apache/tuscany/container/spring/SCAXMLBeanDefinitionParser.java
===
--- java/org/apache/tuscany/container/spring/SCAXMLBeanDefinitionParser.java
(revision 409683)
+++ java/org/apache/tuscany/container/spring/SCAXMLBeanDefinitionParser.java
(working copy)
@@ -10,11 +10,11 @@
*
* @version $$Rev$$ $$Date$$
*/
-public class SCAXmlBeanDefinitionParser extends DefaultXmlBeanDefinitionParser
{
+public class SCAXMLBeanDefinitionParser extends DefaultXmlBeanDefinitionParser
{
private CompositeComponentType componentType;
-public SCAXmlBeanDefinitionParser(CompositeComponentType componentType) {
+public SCAXMLBeanDefinitionParser(CompositeComponentType componentType) {
this.componentType = componentType;
}
Index: java/org/apache/tuscany/container/spring/SpringComponentTypeLoader.java
===
--- java/org/apache/tuscany/container/spring/SpringComponentTypeLoader.java
(revision 409683)
+++ java/org/apache/tuscany/container/spring/SpringComponentTypeLoader.java
(working copy)
@@ -7,12 +7,12 @@
import org.springframework.beans.factory.xml.XmlBeanDefinitionReader;
import org.springframework.context.support.GenericApplicationContext;
import org.springframework.core.io.Resource;
+import org.springframework.core.io.support.PathMatchingResourcePatternResolver;
/**
- * Loads a component type for a Spring codeApplicationContext/code. The
impplementation creates a new
- * instance of a Spring application context which is configured with SCA
namespace handlers for generating
- * component type information
- *
+ * Loads a component type for a Spring codeApplicationContext/code. The
impplementation creates a new instance of a Spring application context
+ * which is configured with SCA namespace handlers for generating component
type information
+ *
* @version $$Rev$$ $$Date$$
*/
public class SpringComponentTypeLoader implements
ComponentTypeLoaderSpringImplementation {
@@ -21,7 +21,9 @@
DefaultListableBeanFactory beanFactory = new
DefaultListableBeanFactory();
CompositeComponentType componentType = new CompositeComponentType();
XmlBeanDefinitionReader reader = new
SCABeanDefinitionReader(beanFactory, componentType);
-Resource resource = null; //FIXME
+PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver(deploymentContext.getClassLoader());
+String contextLocation = implementation.getContextLocation();
+Resource resource = resolver.getResource(contextLocation);
reader.loadBeanDefinitions(resource);
GenericApplicationContext ctx = new
GenericApplicationContext(beanFactory);
ctx.refresh();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cross language interop testing
A long time ago I posted about doing some interoperability testing. I've got back to this now and I've put some ideas about how we do this on the wiki, here (http://wiki.apache.org/ws/Tuscany/Interop). At a high level we have two products to consider for interoperability testing, SDO and SCA. This testing should be performed across all implementations, i.e. Java, C++ and PHP. As it stands the only available SCA implementation that can talk to anything else is Java (C++ is nearly there with Axis2 integration going on as we speak) so we can skip the SCA interoperability conversation for the time being. That brings us to SDO. SDO interoperability involves successfully moving SDO data (instance, model and/or change history data) from one implementation of SDO to another. The scenarios section gives a few ideas about why we might want to do this. This is not intended to be a complete list so any more SDO interoperability scenarios you can think of are gratefully accepted. We have Java, C++ and PHP implementations of SDO to date but the features available vary slightly across these implementations. From an interoperability point of view Kelvin and myself talked offline and listed the features that seemed important in the Features section. You will note that we marked which implementations currently support which features. Is this assessment correct? The order column simply indicates which order the tests could be constructed in, for example, to get my head round this process I have made a start on the test which involves reading an XML document and writing it out again via the XMLHelper/DAS (item 1.1). This seems like an obvious place to start while, for example, the Axiom serialization code is note done yet in C++ so it would be difficult to start with that. In general the approach to this testing can be fairly simple I believe. For each implementation we write a test program that performs the required test, e.g. read and write an XML file. Then we compare: A/ the input with the output to check that it works for an individual implantation B/ the output of all of the implementations to check interoperability. If all of the inputs and outputs in A match there should be no issue here. So if we lay these tests out in order I would expect to do the following in Java, C++ and PHP where the feature is supported 1.1. Read an XML file and write it out again 1.2. Read an XML file and write out an XSD file 2.1 Read and write Records from a database 3.1 Read XML and write Axiom 3.2 Read Axiom and write XML 4 Serialize XML from/To SDO – I'm not sure that this is different from 1.1at present as I seen documents mention it but haven't tried it 1.3 Read an XML file and make changes before writing it back out again. Changes to be made through both dynamic and generated interfaces 4.2 Read from a database and make changes before writing is back out again. Changes to be made through both dynamic and generated interfaces As I mentioned previously I've had a go at 1.1. This first involved creating XSD files to include all of the type mappings defined in the SDO 2.0.1specification. I have this now and am able to pass it in and out of SDO in Java and C++. PHP is still To Do. The results are included in the schema feature table and I will raise JIRA as I investigate what I have found in more detail. Now I have the XML schema the other XML tests become easier as, to a great extent, they are just variations on a theme. I will have to generate a relational schema to match of course. So, is this going to work and is it sufficient? Any thoughts you have on any of this are gratefully received on the mailing list. It may be useful for us to have an IRC chat based on feedback to discuss the best way forward. I will post with details depending on what feedback I get. An unresolved issue is what to do with the test code and files that this process will generate. The test code will happily live within each project somewhere (where is a good place in each project structure?), for example, it could be Java: tuscany/java/sdo/impl/src/test/org/apache/Tuscany/sdo/interop C++: tuscany/cpp/sdo/runtime/core/interop PHP: tuscanyphp/sdo-1.0.1/tests/interop The input files themselves are common across all projects as are the results of cross implementation file comparisons. So where should they live. Maybe the thing to do is just pick on project, C++ or Java, and put the common files there. We have a UK public holiday on Monday but I'll be back to this on Tuesday.
Re: Getting list of components in a module
Yea sorry got called into other things yesterday.
We definitely don't want to cast like that since
AbstractCompositeContext is not a public API and it involves touching
internal structures. This use case brings up an interesting set of
issues. It sounds as if what you need is a management API. Related to
this, I don't think we should allow arbitrary client code to dig
around into a composite context since it's not really part of the SCA
programming model and, probably more importantly, it's a potential
security concern. So, we will probably need to define some security
mechanism. Also, what we probably want is access to runtime
artifacts, not what's in a particular SCDL, since the latter may not
be in sync with the current runtime state.
Maybe we could use this to start a discussion of what type of
management API is needed?
Jim
On May 26, 2006, at 5:08 AM, ant elder wrote:
Never did get any answer on this. Having the class below in the rhino
container works as it uses the AbstractCompositeContext package
name, but it
seesm a bit hacky:
package org.apache.tuscany.core.context.impl;
public class ComponentNamesAccessor {
public static SetString getComponentNames(ModuleContext
moduleContext)
{
if (moduleContext instanceof AbstractCompositeContext) {
MapString, ScopeContext x = ((AbstractCompositeContext)
moduleContext).scopeIndex;
return x.keySet();
}
return null;
}
}
...ant
On 5/24/06, ant elder [EMAIL PROTECTED] wrote:
Jim, this would be unmanaged code, not in a component, so it
doesn't look
like there is any API for this. The idea of TUSCANY-417 is an
interactive
JavaScript shell along the lines of what Jeremy described as a
first-class
client environment for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed
code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've a J2SE client that needs to get a list of all the components
defined in
the current module, is that possible? There used to be the
getMetaData
method but thats been removed now. If there is no easy way right
now could
i add something?
...ant
-
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-432) JavaProeject page: some links don't work and the flow can be improved.
JavaProeject page: some links don't work and the flow can be improved. -- Key: TUSCANY-432 URL: http://issues.apache.org/jira/browse/TUSCANY-432 Project: Tuscany Type: Improvement Components: Website Versions: Java-M1-website Reporter: haleh mahbod On Java Project page: 1. In Systems requirements table, the link for quick reference to maven does not work. 2. Text should be corrected for Tomcat setup: • Dowload apache-tomcat-5.5.17 Tomcat Zip here. to the tuscany\java\distribution\tomcat-overlay directory. Do not unpack. --- should get rid of 'here' after tomcat.zip' 3. There is no way for users to know that there is a 'Creating Tuscany' or 'Environment Script' section in the java page. We could add text at the beginning of System Setup section to say the first step is to downloading is to create your Tuscany directory and environment scripts (AND link the text to the sections) 4. Running the samples: Need a link to gettingstarted.htm to the right place or mention where user can find it. 5. The Javadoc link at the top should point to javadocs. It is currently saying TBD. -- 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++ Release
+1 from me too. As well as the list of tasks that's on the Wiki, it would be good to discuss a list of functionality that will be in the release - I seem to remember seeing a list somewhere - does anyone know where or was it just my overactive imagination? Cheers Andrew
Re: Getting list of components in a module
Yeah, as Jim says this is likely to stop working later when we tighten
up classloading and security - application code won't be able to see
the internal class to cross-cast and the calls should probably have a
security check on it.
To make this work longer term I think we should add some management
interfaces to the SPI package and commit to them longer term. We need
to put some thought into this though to make sure the management API
is compatible with JMX (specifically Open MBeans) and one of the
web-services management specs (e.g. WS-DM). Sounds like we need
another thread on that ...
I'd also suggest separating the shell from the Rhino container
implementation as we wouldn't want them to have the same permissions
and putting it in a separate codebase is an easy way to do that.
--
Jeremy
On 5/26/06, Jim Marino [EMAIL PROTECTED] wrote:
Yea sorry got called into other things yesterday.
We definitely don't want to cast like that since
AbstractCompositeContext is not a public API and it involves touching
internal structures. This use case brings up an interesting set of
issues. It sounds as if what you need is a management API. Related to
this, I don't think we should allow arbitrary client code to dig
around into a composite context since it's not really part of the SCA
programming model and, probably more importantly, it's a potential
security concern. So, we will probably need to define some security
mechanism. Also, what we probably want is access to runtime
artifacts, not what's in a particular SCDL, since the latter may not
be in sync with the current runtime state.
Maybe we could use this to start a discussion of what type of
management API is needed?
Jim
On May 26, 2006, at 5:08 AM, ant elder wrote:
Never did get any answer on this. Having the class below in the rhino
container works as it uses the AbstractCompositeContext package
name, but it
seesm a bit hacky:
package org.apache.tuscany.core.context.impl;
public class ComponentNamesAccessor {
public static SetString getComponentNames(ModuleContext
moduleContext)
{
if (moduleContext instanceof AbstractCompositeContext) {
MapString, ScopeContext x = ((AbstractCompositeContext)
moduleContext).scopeIndex;
return x.keySet();
}
return null;
}
}
...ant
On 5/24/06, ant elder [EMAIL PROTECTED] wrote:
Jim, this would be unmanaged code, not in a component, so it
doesn't look
like there is any API for this. The idea of TUSCANY-417 is an
interactive
JavaScript shell along the lines of what Jeremy described as a
first-class
client environment for JavaScript.
...ant
On 5/24/06, Jim Marino [EMAIL PROTECTED] wrote:
Can you explain why you need the list of components? For managed
code
(i.e. in a component) the spec defines a way to get the metadata
associated with a module.
Jim
On May 24, 2006, at 1:30 AM, ant elder wrote:
I've a J2SE client that needs to get a list of all the components
defined in
the current module, is that possible? There used to be the
getMetaData
method but thats been removed now. If there is no easy way right
now could
i add something?
...ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deserializing SDOs using scoped registries
Please see my further comments. Thanks, Raymond - Original Message - From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, May 26, 2006 11:45 AM Subject: Re: Deserializing SDOs using scoped registries Raymond, Thanks for the input. See comments below. - Ron - Original Message From: Raymond Feng [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, May 26, 2006 1:04:29 PM Subject: Re: Deserializing SDOs using scoped registries Hi, I have some comments as well. Thanks, Raymond - Original Message - From: Ron Gavlin [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Friday, May 26, 2006 9:44 AM Subject: Re: Deserializing SDOs using scoped registries Frank, My model is similar to the one listed below. The http://example.org/ord namespace is statically registered while the http://example.org/info/zipcode and http://example.org/info/street namespaces are dynamically registered. In my application, add'l info namespaces maybe registered/de-registered on the fly so the info namespaces can't be statically registered up front. In both the client and server JVMs, the ord namespace is statically registered and the info namespaces are dynamically registered. I am attempting to pass (serialize/de-serialize) a DataGraph containing the Sample Instance DataObject below between the client and server JVMs. Currently, neither Tuscany SDO nor EMF/SDO out of the box appear to support this mixed static/dynamic type of model (note how InfoType in the ord namespace is extended in each of the info namespaces). I subclassed several Tuscany and EMF classes (including XSDEcoreBuilder) to add this support. With these enhancements, XMLHelper.INSTANCE.load() successfully loads the Sample Instance as a DataObject using this mixed model. I'm currently investigating whether I can contribute these modifications back to Tuscany SDO and EMF. rfengThis is an interesting topic. The basic question is: Do we want to honor the static model if its namespace is referenced by the XSD when XSD2Ecore is performed? . For example, your XSD has something like element name=customer type=customer:Customer/ and you already have a static model registered for customer. I have some similar code as you described.rfeng rg Yes, you have described a more mainstream case. Our model in whiich a dynamic type extends a static type is probably less common and more demanding on the XMLLoader. rg Now let me respond to your questions. 1a. You are correct, the dynamic models on the client side are stored in local TypeHelper registries, but the CORBA RMI only has access to the global EMF registry. (I solved this problem by stealing the dynamic EPackages from the TypeHelper's ExtendedMetaData and registering them myself in the global EMF registry. Ugly, but it worked. rfengWhen you say local type helper, is it the one assoicated with the application classloader? If so, I believe CORBA code has access to it since the global registry will delegate to it./rfeng rg The local TypeHelper registry I am referring to is the extendedMetaData member variable within the Tuscany TypeHelperImpl instance. When CORBA code accesses the registry for de-serialization, does it know to how to navigate beyond the global registry into the extendedMetaData within this particular TypeHelperImpl instance?rg rfengI checked the Tuscany SDO code and it seems that each TypeHelper has its own registry which delegates (only get, not put) to EPackage.Registry.INSTNACE which is classloader-aware.In this case, I understand CORBA code cannot assess the model in your TypeHelper instance. It leads to an interesting question: What registry does the DataGraph/DataObject java deserialization use? So really, we need to have a scope-aware registry and SDO should provide such a pluggability so that it will resolve to the same TypeHelper for serialization and deserialization in a given context./rfeng 1b. Not quite. The server-side CORBA RMI code accesses the server-side, statically-registered ord package w/out difficulty using the global classloader-specific delegate registries. However, the dynamic models stored in the TypeHelper registries on the server cannot be accessed by the CORBA RMI code (same problem as in 1a above). However, the trick described above didn't work on the server presumably because of the server classloader-specific delegate registries. First, do you have any ideas how problem 1b can be solved? Second, assume for the moment that I had a pure dynamic model, i.e., the ord namespace was dynamically rather than statically registered. How would the CORBA RMI code get a reference to the appropriate, local TypeHelper registries to de-serialize the DataGraph and its child DataObjects? rfengBy my experience, I didn't have problems in CORBA serialization/deserialization (passing DataObject over RMI/IIOP) with dynamic model using EMF/SDO 1.0./rfeng rg My server application is
Re: Getting list of components in a module
Sebastien removed it back in Feb (r379362) as the whole view of metadata in the spec was fuzzy and going to be reviewed (which has not happened yet). -- Jeremy On 5/26/06, Paul Fremantle [EMAIL PROTECTED] wrote: On 5/24/06, ant elder [EMAIL PROTECTED] wrote: I've a J2SE client that needs to get a list of all the components defined in the current module, is that possible? There used to be the getMetaData method but thats been removed now. Removed from where? Paul -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting list of components in a module
Wouldn't it be better to wait till the spec is updated? If you are publishing a release that doesn't match the spec won't that confuse people? Paul On 5/26/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Sebastien removed it back in Feb (r379362) as the whole view of metadata in the spec was fuzzy and going to be reviewed (which has not happened yet). -- Jeremy On 5/26/06, Paul Fremantle [EMAIL PROTECTED] wrote: On 5/24/06, ant elder [EMAIL PROTECTED] wrote: I've a J2SE client that needs to get a list of all the components defined in the current module, is that possible? There used to be the getMetaData method but thats been removed now. Removed from where? Paul -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com
[jira] Resolved: (TUSCANY-432) JavaProeject page: some links don't work and the flow can be improved.
[ http://issues.apache.org/jira/browse/TUSCANY-432?page=all ] Rick Rineholt resolved TUSCANY-432: --- Fix Version: Java-M1 Java-M1-website Java-M1-tentative Java-M2 Java-Mx Resolution: Fixed Feel I addressed the specific items listed. JavaProeject page: some links don't work and the flow can be improved. -- Key: TUSCANY-432 URL: http://issues.apache.org/jira/browse/TUSCANY-432 Project: Tuscany Type: Improvement Components: Website Versions: Java-M1-website Reporter: haleh mahbod Fix For: Java-M1, Java-Mx, Java-M1-tentative, Java-M1-website, Java-M2 On Java Project page: 1. In Systems requirements table, the link for quick reference to maven does not work. 2. Text should be corrected for Tomcat setup: ? Dowload apache-tomcat-5.5.17 Tomcat Zip here. to the tuscany\java\distribution\tomcat-overlay directory. Do not unpack. --- should get rid of 'here' after tomcat.zip' 3. There is no way for users to know that there is a 'Creating Tuscany' or 'Environment Script' section in the java page. We could add text at the beginning of System Setup section to say the first step is to downloading is to create your Tuscany directory and environment scripts (AND link the text to the sections) 4. Running the samples: Need a link to gettingstarted.htm to the right place or mention where user can find it. 5. The Javadoc link at the top should point to javadocs. It is currently saying TBD. -- 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-213) Errors in config model result in NPE rather than helpful error message
[ http://issues.apache.org/jira/browse/TUSCANY-213?page=all ] Kevin Williams reassigned TUSCANY-213: -- Assign To: Kevin Williams Errors in config model result in NPE rather than helpful error message -- Key: TUSCANY-213 URL: http://issues.apache.org/jira/browse/TUSCANY-213 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-Mx Attachments: invalidConfig.txt Typos in the config.xml can lead to meaningless NPE errors. For example, changing from the following change in OrdersOrderDetailsConfig.xml Relationship name=ORDERDETAILS primaryKeyTable=ANORDER foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship to this ... Relationship name=ORDERDETAILS primaryKeyTable= foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship results in a harsh NPE rather than of a cozy message exlaining that we are sorry but we have no table/property named -- 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-213) Errors in config model result in NPE rather than helpful error message
[ http://issues.apache.org/jira/browse/TUSCANY-213?page=all ] Kevin Williams resolved TUSCANY-213: Resolution: Fixed Errors in config model result in NPE rather than helpful error message -- Key: TUSCANY-213 URL: http://issues.apache.org/jira/browse/TUSCANY-213 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-Mx Attachments: invalidConfig.txt Typos in the config.xml can lead to meaningless NPE errors. For example, changing from the following change in OrdersOrderDetailsConfig.xml Relationship name=ORDERDETAILS primaryKeyTable=ANORDER foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship to this ... Relationship name=ORDERDETAILS primaryKeyTable= foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship results in a harsh NPE rather than of a cozy message exlaining that we are sorry but we have no table/property named -- 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] Closed: (TUSCANY-213) Errors in config model result in NPE rather than helpful error message
[ http://issues.apache.org/jira/browse/TUSCANY-213?page=all ] Kevin Williams closed TUSCANY-213: -- Verified with 409741 Errors in config model result in NPE rather than helpful error message -- Key: TUSCANY-213 URL: http://issues.apache.org/jira/browse/TUSCANY-213 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-Mx Attachments: invalidConfig.txt Typos in the config.xml can lead to meaningless NPE errors. For example, changing from the following change in OrdersOrderDetailsConfig.xml Relationship name=ORDERDETAILS primaryKeyTable=ANORDER foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship to this ... Relationship name=ORDERDETAILS primaryKeyTable= foreignKeyTable=ORDERDETAILS many=true KeyPair primaryKeyColumn=ID foreignKeyColumn=ORDERID/ /Relationship results in a harsh NPE rather than of a cozy message exlaining that we are sorry but we have no table/property named -- 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] Closed: (TUSCANY-186) Need APIs for CommandFactory (and probably CommandGroupFactory) to accept Config instance in addition to the current API for FileStream
[ http://issues.apache.org/jira/browse/TUSCANY-186?page=all ] Kevin Williams closed TUSCANY-186: -- Verified with 409741 Need APIs for CommandFactory (and probably CommandGroupFactory) to accept Config instance in addition to the current API for FileStream Key: TUSCANY-186 URL: http://issues.apache.org/jira/browse/TUSCANY-186 Project: Tuscany Type: New Feature Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-Mx Attachments: commandgroup.txt -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-433) User provided CUD with partial update results in NPE
User provided CUD with partial update results in NPE Key: TUSCANY-433 URL: http://issues.apache.org/jira/browse/TUSCANY-433 Project: Tuscany Type: Bug Components: Java DAS RDB Versions: Java-Mx Reporter: Kevin Williams ApplyChanges with partil userprovided update statement fails with NPE. Test case DefectTests.readModifyAply and readModifyApply1() demonstrate this bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
