Re: Trouble with aggregating definitions.xml in distro
snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon
Re: Moving ServiceDiscovery and related classes to tuscany-util
On Fri, Feb 29, 2008 at 8:51 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 7:34 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. Simon Agree about moving it out of contributions but how about to avoid another new module just to a .utils package in the spi module? I think everything that needs this would already be including the tuscany-core-spi module. ..ant
Re: Moving ServiceDiscovery and related classes to tuscany-util
On Fri, Feb 29, 2008 at 7:34 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. Simon
Re: [Java SDO] Need help in completing release management for SDO 1.1-incubating
Amita, such a shame when you are so nearly there, however, I am happy to pick it up from here. Many thanks for getting it so far. Kelvin. On 29/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi All, I will not be able to continue doing the release management activities from now on for the ongoing SDO release. It will be really great if somebody can pick the thread and complete what is remaining in the release. Regards, Amita
[jira] Updated: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
[
https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1997:
---
Attachment: tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar
Here's a jar containing the fix rebased to the 1.0 code level. This has built
ok for me but i'm getting some security test failures running with it, i
suspect these are an environment problem with the way i'm adding it in to the
backlevel code without using a full 1.0 local build but you'll need to test it
in your environment to be sure. The 1.0 code doesn't have some changes in the
1.1 code so i've had to include more code changes, the complete diff for the
patched jar is:
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(working copy)
@@ -48,7 +48,11 @@
// ensure connections are tracked so that they can be closed by the
reference binding
MessageContext requestMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
-requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+//requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+Options opt = requestMC.getOptions();
+opt.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
+opt.setUseSeparateListener(true);
+opt.setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION,Boolean.TRUE);
operationClient.execute(false);
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(working copy)
@@ -52,8 +52,10 @@
import org.apache.axis2.description.WSDL11ToAxisServiceBuilder;
import org.apache.axis2.description.WSDL2Constants;
import org.apache.axis2.transport.http.HTTPConstants;
+import org.apache.axis2.util.threadpool.ThreadPool;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
+import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
import org.apache.tuscany.sca.assembly.AbstractContract;
import org.apache.tuscany.sca.binding.ws.WebServiceBinding;
import org.apache.tuscany.sca.contribution.Contribution;
@@ -108,7 +110,26 @@
AxisService axisService =
createClientSideAxisService(wsdlDefinition, serviceQName,
portName, new Options());
+HttpClient httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
+if (httpClient == null)
+{
+MultiThreadedHttpConnectionManager connectionManager = new
MultiThreadedHttpConnectionManager();
+HttpConnectionManagerParams connectionManagerParams = new
HttpConnectionManagerParams();
+connectionManagerParams.setDefaultMaxConnectionsPerHost(2);
+connectionManagerParams.setTcpNoDelay(true);
+connectionManagerParams.setStaleCheckingEnabled(true);
+connectionManagerParams.setLinger(0);
+connectionManager.setParams(connectionManagerParams);
+httpClient = new HttpClient(connectionManager);
+configContext.setThreadPool(new ThreadPool(1, 5));
+configContext.setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
+ Boolean.TRUE);
+configContext.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
+ httpClient);
+}
+
return new ServiceClient(configContext, axisService);
+
} catch (AxisFault e) {
throw new RuntimeException(e); // TODO: better exception
}
Axis binding does not allow external configuration to increase the number of
the maximum connections opened.
Key: TUSCANY-1997
URL: https://issues.apache.org/jira/browse/TUSCANY-1997
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Environment: Solaris , Windows , Websphere , Tomcat
Reporter: Catalin Boloaja
Assignee: Jean-Sebastien Delfino
Fix For: Java-SCA-1.2
Attachments:
Re: Trouble with aggregating definitions.xml in distro
Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon
[jira] Updated: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
[ https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1997: --- Attachment: (was: tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar) Axis binding does not allow external configuration to increase the number of the maximum connections opened. Key: TUSCANY-1997 URL: https://issues.apache.org/jira/browse/TUSCANY-1997 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Environment: Solaris , Windows , Websphere , Tomcat Reporter: Catalin Boloaja Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Attachments: tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar, tuscany-binding-ws-axis2-1.1-TUSCANY-1997.jar In a high volume situation the default setting for Axis2 is 2 connections per host. The default protocol being HTTP 1.1 , this means that only 2 POST requests can be issued at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
[
https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1997:
---
Attachment: tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar
Sorry typo, here's the real jar and the correct diff:
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(working copy)
@@ -48,7 +48,11 @@
// ensure connections are tracked so that they can be closed by the
reference binding
MessageContext requestMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
-requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+//requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+Options opt = requestMC.getOptions();
+opt.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
+opt.setUseSeparateListener(true);
+opt.setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION,Boolean.TRUE);
operationClient.execute(false);
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(working copy)
@@ -52,8 +52,10 @@
import org.apache.axis2.description.WSDL11ToAxisServiceBuilder;
import org.apache.axis2.description.WSDL2Constants;
import org.apache.axis2.transport.http.HTTPConstants;
+import org.apache.axis2.util.threadpool.ThreadPool;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
+import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
import org.apache.tuscany.sca.assembly.AbstractContract;
import org.apache.tuscany.sca.binding.ws.WebServiceBinding;
import org.apache.tuscany.sca.contribution.Contribution;
@@ -78,6 +80,8 @@
private ServiceClient serviceClient;
private static final QName SOAP12_INTENT = new
QName(http://www.osoa.org/xmlns/sca/1.0;, soap12);
+public static int httpMaxConnections = 2;
+
public Axis2ServiceClient(RuntimeComponent component,
AbstractContract contract,
WebServiceBinding wsBinding,
@@ -108,7 +112,26 @@
AxisService axisService =
createClientSideAxisService(wsdlDefinition, serviceQName,
portName, new Options());
+HttpClient httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
+if (httpClient == null)
+{
+MultiThreadedHttpConnectionManager connectionManager = new
MultiThreadedHttpConnectionManager();
+HttpConnectionManagerParams connectionManagerParams = new
HttpConnectionManagerParams();
+
connectionManagerParams.setDefaultMaxConnectionsPerHost(httpMaxConnections);
+connectionManagerParams.setTcpNoDelay(true);
+connectionManagerParams.setStaleCheckingEnabled(true);
+connectionManagerParams.setLinger(0);
+connectionManager.setParams(connectionManagerParams);
+httpClient = new HttpClient(connectionManager);
+configContext.setThreadPool(new ThreadPool(1, 5));
+configContext.setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
+ Boolean.TRUE);
+configContext.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
+ httpClient);
+}
+
return new ServiceClient(configContext, axisService);
+
} catch (AxisFault e) {
throw new RuntimeException(e); // TODO: better exception
}
Axis binding does not allow external configuration to increase the number of
the maximum connections opened.
Key: TUSCANY-1997
URL: https://issues.apache.org/jira/browse/TUSCANY-1997
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Environment: Solaris , Windows , Websphere , Tomcat
Reporter: Catalin Boloaja
Assignee: Jean-Sebastien Delfino
Fix For: Java-SCA-1.2
Attachments:
Re: Classloading code in core contribution processing
On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: On 2/22/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Great to see a *test* case for cycles, but my question was: Do you have a *use* case for cycles and partial packages right now or can it be fixed later? Rajini Sivaram wrote: No, I dont have an use-case, at least not an SCA one. But there are plenty of them in OSGi - eg. Tuscany modules cannot run in OSGi without support for split-packages. Of course you can fix it later. I'm not arguing for or against fixing it now or later, I'm trying to get the real use case to make a decision based on concrete grounds. Can you point me to your OSGi use cases, or help me understand Tuscany modules cannot run in OSGi without support for split packages? Tuscany node and domain code are split into three modules each for API, SPI and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl. The API module defines a set of classes in org.apache.tuscany.sca.nodeand the SPI module extends this package with more classes. So the package org.apache.tuscany.sca.node is split across tuscany-node-api and tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest entries for Tuscany modules, we would get three OSGi bundles corresponding to the node modules. And the API and SPI bundles have to specify that they use split-packages. It would obviously have been better if API and SPI used different packages, but the point I am trying to make is that splitting packages across modules is not as crazy as it sounds, and split packages do appear in code written by experienced programmers. IMO, supporting overlapping package import/exports is more important with SCA contributions than with OSGi bundles since SCA contributions can specify wildcards in import.java/export.java. eg. If you look at packaging tuscany-contribution and tuscany-contribution-impl where tuscany-contribution-impl depends on tuscany-contribution, there is no clear naming convention to separate the two modules using a single import/export statement pair. So if I could use wildcards, the simplest option that would avoid separate import/export statements for each subpackage (as required in OSGi) would be to export org.apache.tuscany.sca.contribution* from tuscany-contribution and import org.apache.tuscany.sca.contribution* in tuscany-contribution-impl. The sub-packages themselves are not shared but the import/export namespaces are. We need to avoid cycles in these cases. Again, there is a way to avoid sharing package spaces, but it is simpler to share, and there is nothing in the SCA spec which stops you sharing packages across contributions. I dont think the current model resolver code which recursively searches exporting contributions for artifacts is correct anyway - even for artifacts other than classes. IMO, when an exporting contribution is searched for an artifact, it should only search the exporting contribution itself, not its imports. And that would avoid cycles in classloading. I would still prefer not to intertwine classloading and model resolution because that would unnecessarily make classloading stack traces which are complex anyway, even more complex that it needs to be. But at least if it works all the time, rather than run into stack overflows, I might not have to look at those stack traces and this will convince me to help fix it now :) Thanks. It is not broken now - you have to break it first and then fix it :-). I have reviewed the model resolution and classloading code and found the following: - Split namespaces are currently supported (for example by the WSDL and XSD resolvers). The model resolver mechanism does not have an issue with split namespaces. - The Java import/export resolvers do not seem to support split packages (if I understood that code which was quite tricky), but that's an issue in that Java import/export specific code, which just needs to be fixed. I'll work on it. - The interactions between the Java import/export listener, the model resolvers and the ContributionClassLoader are way too complicated IMHO. That complexity is mostly caused by ContributionClassLoader, I'll try to show a simpler implementation in a few days. - Dependency cycles are an exception in Java as build tools like Maven don't support them, but can exist in XSD for example. Supporting cycles just requires a simple fix to the import model resolvers, I'll help fix that too. Hope this helps. -- Jean-Sebastien It doesn't feel like there is agreement on the approach yet so would you hold off committing changes to see if we can get better consensus? Reading through the thread I'm not sure that I properly understand exactly what it is thats broken with the code as it
[jira] Assigned: (TUSCANY-2055) ServiceReference.getConversationID() not returning generated conversation IDs
[
https://issues.apache.org/jira/browse/TUSCANY-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-2055:
---
Assignee: Simon Laws
ServiceReference.getConversationID() not returning generated conversation IDs
-
Key: TUSCANY-2055
URL: https://issues.apache.org/jira/browse/TUSCANY-2055
Project: Tuscany
Issue Type: Bug
Components: Specification
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Simon Laws
ServiceReference.getConversationID() returns null unless the Conversation ID
is set by the user.
This is the current implementaiton:
public Object getConversationID() {
return conversationID;
}
It seems that that if the cached ID is null, and there is a valid related
Converasation object then the impl should return the related
Conversation.getConversationID.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: Trouble with aggregating definitions.xml in distro
Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. Ant, thanks for point me to this. :) - Venkat On Fri, Feb 29, 2008 at 5:52 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
Re: Trouble with aggregating definitions.xml in distro
I only pointed at that as an example of how to write a transformer, I hadn't realized it did what we needed either :) ...ant On Fri, Feb 29, 2008 at 12:52 PM, Venkata Krishnan [EMAIL PROTECTED] wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. Ant, thanks for point me to this. :) - Venkat On Fri, Feb 29, 2008 at 5:52 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon
[jira] Commented: (TUSCANY-2055) ServiceReference.getConversationID() not returning generated conversation IDs
[
https://issues.apache.org/jira/browse/TUSCANY-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573725#action_12573725
]
Simon Laws commented on TUSCANY-2055:
-
It seems that the Java Annotations and API V1 spec is a little inconsistent.
521 1.6.6.2. Accessing Conversation IDs from Clients
522 Whether the conversation ID is chosen by the client or is generated by the
system, the client may access
523 the conversation ID by calling ServiceReference.getConversationID().
924 • getConversationID() - Returns the id supplied by the user that will be
associated with
925 conversations initiated through this reference.
946 • getConversationID() - Returns the identifier for this conversation. If a
user-defined identity had
947 been supplied for this reference then its value will be returned; otherwise
the identity generated by
948 the system when the conversation was initiated will be returned.
Has there been more work to clarify in the spec group?
I believe that the Conversation object represents the current conversation so
you should always go there to get the current conversationID. The
get/setConversationId on the ServiceReference is to allow the user to provide a
conversation ID that will subsequently be used for new conversations. Hence
you won't get the current conversationID by calling getConversationId on
ServiceReference you'll just get whatever you set there manually.
Having said that I did a quick change to the test to make it retrieve the
conversation ID from the Conversation object and needless to say it failed in
other interesting ways. So if we can agree what the intention of the spec is
I'll make the code do that.
ServiceReference.getConversationID() not returning generated conversation IDs
-
Key: TUSCANY-2055
URL: https://issues.apache.org/jira/browse/TUSCANY-2055
Project: Tuscany
Issue Type: Bug
Components: Specification
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Simon Laws
ServiceReference.getConversationID() returns null unless the Conversation ID
is set by the user.
This is the current implementaiton:
public Object getConversationID() {
return conversationID;
}
It seems that that if the cached ID is null, and there is a valid related
Converasation object then the impl should return the related
Conversation.getConversationID.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
On Fri, Feb 29, 2008 at 12:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 11:58 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Yes the shade transformer that we use there just about aggregates the contents of all files found with the path that we specify there. So it also ends up aggregating the definitions.xml just as a text file. So this ends up with multiple sca:definitions elements and then no root element in the aggregated definitions.xml. This is where the problem started. I am looking at a XMLAppender that Ant pointed out. Let me see how it goes. Otherwise I want to try our own shade transformer. Thanks - Venkat On Fri, Feb 29, 2008 at 2:38 PM, Simon Laws [EMAIL PROTECTED] wrote: snip... Could we just add our own Shade transformer that knows how to aggregate the definitions files? Eg TO SUPPORT something like this in the shade plugin config: transformer implementation= org.apache.tuscany.sca.tools.ShadeDefinitionsTransformer resourceMETA-INF/services/definitions.xml/resource /transformer I hadn't noticed the list of shader transformer configurations before in the distribution/bundle pom. How does the appending transformer get applied to definitions.xml as it stands. Is this just default behaviour? Simon So why do we specify transformers for some things and not for others. All the transformers specified are AppendingTransformer which I assume is what is appending the definitions.xml files together by default. Simon I'm not sure i understand what you're asking but here's what i understand happens: The shade plugin is configured in the distribution/bundle/pom.xml. In there we say set the shadedGroupFilter as org.apache.tuscany so all the dependencies in that group get processed by the plugin and by default it will just take all the files in those resources and munged them into the one jar built for the bundle module. That works fine for most files as they have unique names but for files that are duplicated the default will i guess be that the last one processed overwrites the others so all the contents of all the other files gets lost. To fix that we configure a transformer that deals with what to do. For example, we use the AppendingTransformer for all our meta-inf/services files and that just takes the contents of the named file for each it finds it appends the contents into a single file. That works fine for text files but for xml files like definitions.xml there needs to be a way to merge the file contents not to just append the contents at the end. ...ant
What are my chances of being able to inherit behaviour from implementation.java?
Suppose I wanted to create a new implementation that shared much of the behaviour of implementation.java and then added a bit. Suppose I wanted to make implementation.servlet for example, to be an implementation that did what implement.java does WRT understanding @Reference and @Property and getters and setters, but did some extra - for example looked in the web.xml file for the servlet and added some extra properties. How could I architect this to take advantage of all the code that already exists within the support for implementation.java? Matthew Peters Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Trouble with aggregating definitions.xml in distro
Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2056) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) when using binding.ws
[ https://issues.apache.org/jira/browse/TUSCANY-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stucky updated TUSCANY-2056: --- Attachment: test.zip This is nearly the same eclipse project as in TUSCANY-2028. I only changed the composite to let some components use binding.ws and modified the Interface of Gamma slightly. Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) when using binding.ws Key: TUSCANY-2056 URL: https://issues.apache.org/jira/browse/TUSCANY-2056 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky Attachments: test.zip This problem is related to TUSCANY-2028. It is exactly the same use case, but instead of the default binding (sca) I now use binding.ws. And as in Tuscany 1.0.1 with binding.sca the Conversation is not reused. So I guess the fix that went into Tuscany 1.1 did only affect binding.sca and not binding.ws. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, February 29, 2008 8:17 AM To: tuscany-dev@ws.apache.org Subject: Re: Trouble with aggregating definitions.xml in distro Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Jean-Sebastien Delfino wrote: Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) Here's your new thread, starting with two statements: I think that contributors should be able to place their definitions.xml files wherever they want in an SCA contribution JAR. I also think that we'll have to support external policy attachments at some point (see the Open CSA POLICY-15 JIRA already discussed on tuscany-dev on other threads), and these policy attachments won't be in a fixed place in the contributions either. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trouble with aggregating definitions.xml in distro
Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Friday, February 29, 2008 8:17 AM To: tuscany-dev@ws.apache.org Subject: Re: Trouble with aggregating definitions.xml in distro Venkata Krishnan wrote: Alright, I played around with https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/XmlAppendingTransformer.javaa bit and it seems like it gives all that I have been looking for - a neat aggregated xml file that is valid. I will now go and see how to plug this in our dist bundle. If I understand correctly, it looks like you're now going away from the solution we discussed before in this thread (and which was going to work), and are going to use the above shade plugin transformer to merge multiple definitions.xml files. I'm OK with that if you make it really work, but at first sight the logic in the XmlAppendingTransformer looks a little 'fragile' :) Can you please try two things? - two definitions.xml files that use different namespaces for their policySets? - two definitions.xml files that use a namespace prefix 'policy' mapped to two different namespaces? If it works, then, great! If it doesn't work you'll just need to write your own shade transformer, and/or contribute a fix to Shade. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2056) Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) when using binding.ws
Conversation does not continue if a Service Reference is passed as a return value (not as a parameter) when using binding.ws Key: TUSCANY-2056 URL: https://issues.apache.org/jira/browse/TUSCANY-2056 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 1.5.0_10 Reporter: Daniel Stucky This problem is related to TUSCANY-2028. It is exactly the same use case, but instead of the default binding (sca) I now use binding.ws. And as in Tuscany 1.0.1 with binding.sca the Conversation is not reused. So I guess the fix that went into Tuscany 1.1 did only affect binding.sca and not binding.ws. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Location of policy definitions in SCA contributions: was: Trouble with aggregating definitions.xml in distro
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: My understanding is that there are two different issues here: 1) Where definitions.xml should be packaged in a SCA contribution? 2) How do we merge multiple definitions.xml when we build the all-in-one binary distro? So I assume Sebastien's proposal is for 1) and the maven/shade discussion is for 2). Am I right? If yes, we should have two separate threads as it becomes confusing. My proposal handled 1 (not forcing definitions.xml to be in a fixed location in the JAR) and 2 (as it didn't require any XML merging). My latest comments below in this email apply to 2 (I'm basically saying if you really want to do this XML merging, then make sure it works). I'm branching a new thread for 1 :) Here's your new thread, starting with two statements: I think that contributors should be able to place their definitions.xml files wherever they want in an SCA contribution JAR. I also think that we'll have to support external policy attachments at some point (see the Open CSA POLICY-15 JIRA already discussed on tuscany-dev on other threads), and these policy attachments won't be in a fixed place in the contributions either. Sorry, pressed send before updating the subject :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why does SDODatabinding set up a default element ?
Hi,
This is part of the changes that we move toward using the JAXWS mapping
rules to map remotable java interface to WSDL. The element names are derived
from the java method signature. For example, if we have the following
interface:
public interface MyService {
AddressSDO getAddress(CustomerSDO customer);
}
We'll have arg0 for customer and return for the return value.
With this, we may end up with a SDO as:
arg0 xsi:type=ns:Customer ../arg0
Assuming ns:Customer is a global type and SDO should be able to deserialize
it. But it seems that SDO can only handle:
sdo:dataObject xmlns:sdo=commonj.sdo xsi:type=ns:Customer
.../sdo:dataObject
So I think it is either a SDO bug or feature request. We can create a simple
testcase in SDO without any SCA code.
Thanks,
Raymond
--
From: Scott Kurz [EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 8:28 PM
To: tuscany-dev@ws.apache.org
Subject: why does SDODatabinding set up a default element ?
Question:
Way back in October in r589154 SDODataBinding.introspect was changed to
propagate the Java dflt elem QName into the XMLType logical with code that
looks like:
Object logical = dataType.getLogical();
if (logical instanceof XMLType) {
elementName = ((XMLType)logical).getElementName();
}
dataType.setLogical(new XMLType(elementName, xmlType));
I'm noticing this breaks some code I had which was relying on the default
behavior in which DataObject2XMLStreamReader would call
SDOContextHelper.getElement() and get back the default elem QName of {
commonj.sdo}dataObject.
(I also noticed when I was going from SDO-AXIOM I didn't have this issue
since the unwrapped-wrapped path in Output2OutputTransformer grabbed the
elem name from the AXIOM/WSDL)
Anyway.. it seems that when I later do XMLStreamReader2DataObject now with
the new dflt elem, the SDO I get is not recognized as matching the
particular SDO type which it should, and so I end up with an instance of
type AnyTypeDataObjectImpl instead of, say, a PersonImpl type.
Maybe it would help me adjust if I could learn what was gained from this
switch.
Could anyone (Raymond) kindly explain please?
Thanks, Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What are my chances of being able to inherit behaviour from implementation.java?
Matthew Peters wrote: Suppose I wanted to create a new implementation that shared much of the behaviour of implementation.java and then added a bit. Suppose I wanted to make implementation.servlet for example, to be an implementation that did what implement.java does WRT understanding @Reference and @Property and getters and setters, but did some extra - for example looked in the web.xml file for the servlet and added some extra properties. How could I architect this to take advantage of all the code that already exists within the support for implementation.java? Matthew Peters We may need to refactor some of that function to make it available to others as a proper SPI. Could you describe the bits you'd want to reuse in more details? - some of the implementation model? - introspection of a Java class and creation of the corresponding componentType model? - injection of properties and references? - invocation? I guess it's different here as a servlet has a fixed interface pattern? - anything else? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-2010) Default binding URI for service from Composite impl component is incorrect
[
https://issues.apache.org/jira/browse/TUSCANY-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-2010:
---
Assignee: Simon Nash
I'm assigning this for Simon by proxy as I just got a call from him saying he
wanted to work on this but couldn't get internet where he is to assign it or
post mail.
Default binding URI for service from Composite impl component is incorrect
--
Key: TUSCANY-2010
URL: https://issues.apache.org/jira/browse/TUSCANY-2010
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0.1
Reporter: Scott Kurz
Assignee: Simon Nash
Priority: Minor
Fix For: Java-SCA-Next
Consider the following two SCDL files, a top-level SCDL with a component
implemented in a 2nd SCDL file:
!-- top-level SCDL excerpt --
component name=MultiplyComponent
implementation.composite name=multiply:MultiplyComposite/
/component
!-- composite impl SCDL excerpt --
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=MultiplyComposite
service name=MultiplyService
promote=InnerMultiplyComponent/MultiplyService
interface.java /
/service
component name=InnerMultiplyComponent
implementation.java... /
/component
/composite
It seems that, based on the current CompositeConfigurationBuilderImpl.java
code in the assembly module, I am going to end up with an effective default
binding URI of MultiplyComponent/MultiplyComponent instead of simply the
correct MultiplyComponent.
It seems like one fix is to change this segment:
// around line 109
Implementation implementation = component.getImplementation();
if (implementation instanceof Composite) {
// Process nested composite
// configureComponents((Composite)implementation,
componentURI); //PROBLEM
configureComponents((Composite)implementation, null);
//SEEMS TO WORK
}
However, I'm not sure if I'm giving this the thought this deserves. For
example I see Sebastien made a change in r592270 and I'm not sure why.
Maybe there's a better solution.Could we possibly want to, in some cases,
do something like:
URI.create(String).relativize(URI.create(String))
in one or more case where we now do:
URI.create(String).resolve(String)
?
Just throwing that out there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2057) Namespace information not preserved by ContributionMetadataProcessor.write()
Namespace information not preserved by ContributionMetadataProcessor.write() Key: TUSCANY-2057 URL: https://issues.apache.org/jira/browse/TUSCANY-2057 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.0.1 Reporter: Brent Daniel Namespace information is not preserved by ContributionMetadataProcessor.write(). You can reproduce this by modifying ContributionMetadataDocumentProcessorTestsCase.testLoad() to add a write at the end. The input XML is: private static final String VALID_XML = ?xml version=\1.0\ encoding=\ASCII\? + contribution xmlns=\http://www.osoa.org/xmlns/sca/1.0\; xmlns:helloworld=\http://helloworld\; + deployable composite=\helloworld:Composite1\/ + deployable composite=\helloworld:Composite2\/ + /contribution; The output from ContributionMetadataProcessor.write() is: ?xml version='1.0' encoding='UTF-8'? contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; deployable composite=ns1:Composite1 / deployable composite=ns1:Composite2 / /contribution -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Comments inline. A) Contribution workspace (containing installed contributions): - Contribution model representing a contribution - Reader for the contribution model - Workspace model representing a collection of contributions - Reader/writer for the workspace model - HTTP based service for accessing the workspace - Web browser client for the workspace service - Command line client for the workspace service - Validator for contributions in a workspace I started looking at step D). Having a rest from URLs :-) In the context of this thread the node can loose it's connection to the domain and hence the factory and the node interface slims down. So Runtime that loads a set of contributions and a composite becomes; create a node add some contributions (addContribution) and mark a composite for starting(currently called addToDomainLevelComposite). start the node stop the node You could then recycle (destroy) the node and repeat if required. This all sound like a suggestion Sebastien made about 5 months ago ;-) I have started to check in an alternative implementation of the node (node2-impl). I haven't changed any interfaces yet so I don't break any existing tests (and the code doesn't run yet!). Anyhow. I've been looking at the workspace code for parts A and B that has recently been committed. It would seem to be fairly representative of the motivating scenario [1]. I don't have detailed question yet but interestingly it looks like contributions, composites etc are exposed as HTTP resources. Sebastien, It would be useful to have a summary of you thoughts on how it is intended to hang together and how these will be used. I've basically created three services: workspace - Provides access to a collection of links to contributions, their URI and location. Also provides functions to get the list of contribution dependencies and validate a contribution. composites - Provides access to a collection of links to the composites present in to the domain composite. Also provides a function returning a particular composite once it has been 'built' (by CompositeBuilder), i.e. its references, properties etc have been resolved. nodes - Provides access to a collection of links to composites describing the implementation.node components which represent SCA nodes. There's another file upload service that I'm using to upload contribution files and other files to some storage area but it's just temporary. I'm using binding.atom to expose the above collections as editable ATOM-Pub collections (and ATOM feeds of contributions, composites, nodes). Here's how I'm using these services as an SCA domain administrator: 1. Add one or more links to contributions to the workspace. They can be anywhere accessible on the network through a URL, or local on disk. The workspace just keeps track of the list. 2. Add one or more composites to the composites collection. They become part of the domain composite. 3. Add one or more composites declaring SCA nodes to the nodes collection. The nodes are described as SCA components of type implementation.node. A node component names the application composite that is assigned to run on it (see implementation-node-xml for an example). 4. Point my Web browser to the various ATOM collections to get: - lists of contributions, composites and nodes - list of contributions that are required by a given contribution - the source of a particular composite - the output of a composite built by CompositeBuilder Here, I'm hoping that the work you've started to assign endpoint info to domain model [2] will help CompositeBuilder produce the correct fully resolved composite. 5. Pick a node, point my Web browser to its composite description and write down: - $node = URL of the composite describing the node - $composite = URL of the application composite that's assigned to it - $contrib = URL the list of contribution dependencies. 6. When you have node2-impl ready :) from the command line do: sca-node $node $composite $contrib this should start the SCA node, which can get its description, composite and contributions from these URLs. or for (6) start the node directly from my Web browser as described in [1], but one step at a time... that can come later when we have the basic building blocks working OK :) I guess these HTTP resource bring a deployment dimension. Local - Give the node contribution URLs that point to the local file system from where the node reads the contribution (this is how it has worked to date) Remote - Give it contribution URLs that point out to HTTP resource so the node can read the contributions from where they are stored in the network Was that the intention? Yes. I don't always want to have to upload contributions to some server or even have to copy them around. The collection of contributions should be able to point to contributions directly in my IDE workspace for example (and it supports that today). [1]
Re: What are my chances of being able to inherit behaviour from implementation.java?
Hi Jean-Sebastien, thanks for a fast response.
What I am most interested in is the introspection and the ability to drive
injection. Life cycle and invocation on the other hand are not a concernt
because servlets have a very defined lifecycle and ideally that should all
be looked after by the web container.
Here is an example:
The .composite file might look like this:
component name=StoreServletServiceComponent
implementation.servlet class=store.StoreServlet/
reference name=catalogService target=CatalogServiceComponent
/
property ... some special servlet-specific properties ...
/property
/component
component name=CatalogServiceComponent
implementation.java class=services.CatalogImpl/
/component
And with the servlet containing a setter for the reference, so looking for
all the world like a java component in this respect
@Reference
public void setCatalogService(Catalog catalogService) {
this.catalogService = catalogService;
}
private Catalog catalogService;
Yet doing something special with some of the properties, presenting them
as servlet init parameters, or example. So, I'm interested in:
1, introspection for references and properties
2. driving injection for references
3. driving injecttion for some properties
4. not doing injection for some other properties but doing something
different for them
Matthew Peters
Jean-Sebastien Delfino [EMAIL PROTECTED]
29/02/2008 16:51
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: What are my chances of being able to inherit behaviour from
implementation.java?
Matthew Peters wrote:
Suppose I wanted to create a new implementation that shared much of the
behaviour of implementation.java and then added a bit. Suppose I
wanted
to make implementation.servlet for example, to be an implementation
that
did what implement.java does WRT understanding @Reference and
@Property
and getters and setters, but did some extra - for example looked in the
web.xml file for the servlet and added some extra properties. How could
I
architect this to take advantage of all the code that already exists
within the support for implementation.java?
Matthew Peters
We may need to refactor some of that function to make it available to
others as a proper SPI. Could you describe the bits you'd want to reuse
in more details?
- some of the implementation model?
- introspection of a Java class and creation of the corresponding
componentType model?
- injection of properties and references?
- invocation? I guess it's different here as a servlet has a fixed
interface pattern?
- anything else?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[jira] Updated: (TUSCANY-2058) The method XSDHelper.isXSD(Type) is returning invalid information
[ https://issues.apache.org/jira/browse/TUSCANY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-2058: Attachment: Test2058.java Sample for XSDHelper.isXSD(Type) issue. The method XSDHelper.isXSD(Type) is returning invalid information - Key: TUSCANY-2058 URL: https://issues.apache.org/jira/browse/TUSCANY-2058 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.1 Attachments: Test2058.java Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the supplied Type object has been defined in the Scope from which the XSDHelper was constructed. In turn, I expect that 'false' will be returned, for a Type object NOT defined in the Scope. In some testing I have performed, I'm seeing that 'true' is always returned, even if the Type is defined outside the Scope being questioned. I will attach a sample. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2058) The method XSDHelper.isXSD(Type) is returning invalid information
The method XSDHelper.isXSD(Type) is returning invalid information - Key: TUSCANY-2058 URL: https://issues.apache.org/jira/browse/TUSCANY-2058 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.1 Based on my understanding, XSDHelper.isXSD(Type) should return 'true' if the supplied Type object has been defined in the Scope from which the XSDHelper was constructed. In turn, I expect that 'false' will be returned, for a Type object NOT defined in the Scope. In some testing I have performed, I'm seeing that 'true' is always returned, even if the Type is defined outside the Scope being questioned. I will attach a sample. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading code in core contribution processing
ant elder wrote: On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: On 2/22/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Great to see a *test* case for cycles, but my question was: Do you have a *use* case for cycles and partial packages right now or can it be fixed later? Rajini Sivaram wrote: No, I dont have an use-case, at least not an SCA one. But there are plenty of them in OSGi - eg. Tuscany modules cannot run in OSGi without support for split-packages. Of course you can fix it later. I'm not arguing for or against fixing it now or later, I'm trying to get the real use case to make a decision based on concrete grounds. Can you point me to your OSGi use cases, or help me understand Tuscany modules cannot run in OSGi without support for split packages? Tuscany node and domain code are split into three modules each for API, SPI and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl. The API module defines a set of classes in org.apache.tuscany.sca.nodeand the SPI module extends this package with more classes. So the package org.apache.tuscany.sca.node is split across tuscany-node-api and tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest entries for Tuscany modules, we would get three OSGi bundles corresponding to the node modules. And the API and SPI bundles have to specify that they use split-packages. It would obviously have been better if API and SPI used different packages, but the point I am trying to make is that splitting packages across modules is not as crazy as it sounds, and split packages do appear in code written by experienced programmers. IMO, supporting overlapping package import/exports is more important with SCA contributions than with OSGi bundles since SCA contributions can specify wildcards in import.java/export.java. eg. If you look at packaging tuscany-contribution and tuscany-contribution-impl where tuscany-contribution-impl depends on tuscany-contribution, there is no clear naming convention to separate the two modules using a single import/export statement pair. So if I could use wildcards, the simplest option that would avoid separate import/export statements for each subpackage (as required in OSGi) would be to export org.apache.tuscany.sca.contribution* from tuscany-contribution and import org.apache.tuscany.sca.contribution* in tuscany-contribution-impl. The sub-packages themselves are not shared but the import/export namespaces are. We need to avoid cycles in these cases. Again, there is a way to avoid sharing package spaces, but it is simpler to share, and there is nothing in the SCA spec which stops you sharing packages across contributions. I dont think the current model resolver code which recursively searches exporting contributions for artifacts is correct anyway - even for artifacts other than classes. IMO, when an exporting contribution is searched for an artifact, it should only search the exporting contribution itself, not its imports. And that would avoid cycles in classloading. I would still prefer not to intertwine classloading and model resolution because that would unnecessarily make classloading stack traces which are complex anyway, even more complex that it needs to be. But at least if it works all the time, rather than run into stack overflows, I might not have to look at those stack traces and this will convince me to help fix it now :) Thanks. It is not broken now - you have to break it first and then fix it :-). I have reviewed the model resolution and classloading code and found the following: - Split namespaces are currently supported (for example by the WSDL and XSD resolvers). The model resolver mechanism does not have an issue with split namespaces. - The Java import/export resolvers do not seem to support split packages (if I understood that code which was quite tricky), but that's an issue in that Java import/export specific code, which just needs to be fixed. I'll work on it. - The interactions between the Java import/export listener, the model resolvers and the ContributionClassLoader are way too complicated IMHO. That complexity is mostly caused by ContributionClassLoader, I'll try to show a simpler implementation in a few days. - Dependency cycles are an exception in Java as build tools like Maven don't support them, but can exist in XSD for example. Supporting cycles just requires a simple fix to the import model resolvers, I'll help fix that too. Hope this helps. -- Jean-Sebastien It doesn't feel like there is agreement on the approach yet so would you hold off committing changes to see if we can get better consensus? Reading through the thread I'm not sure that I properly understand exactly what it is thats broken with the code as it is, would you be able to create a testcase that shows what it is that is broken to help us
[jira] Assigned: (TUSCANY-2057) Namespace information not preserved by ContributionMetadataProcessor.write()
[ https://issues.apache.org/jira/browse/TUSCANY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-2057: Assignee: Luciano Resende Namespace information not preserved by ContributionMetadataProcessor.write() Key: TUSCANY-2057 URL: https://issues.apache.org/jira/browse/TUSCANY-2057 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.0.1 Reporter: Brent Daniel Assignee: Luciano Resende Namespace information is not preserved by ContributionMetadataProcessor.write(). You can reproduce this by modifying ContributionMetadataDocumentProcessorTestsCase.testLoad() to add a write at the end. The input XML is: private static final String VALID_XML = ?xml version=\1.0\ encoding=\ASCII\? + contribution xmlns=\http://www.osoa.org/xmlns/sca/1.0\; xmlns:helloworld=\http://helloworld\; + deployable composite=\helloworld:Composite1\/ + deployable composite=\helloworld:Composite2\/ + /contribution; The output from ContributionMetadataProcessor.write() is: ?xml version='1.0' encoding='UTF-8'? contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; deployable composite=ns1:Composite1 / deployable composite=ns1:Composite2 / /contribution -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Change Tuscany Charter to remove SDO reference
kelvin goodson wrote: Please vote to alter the wording of the existing draft Tuscany charter as discussed in http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/[EMAIL PROTECTED] to the following WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Projectt Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the SCA standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: Adriano Crestaniadrianocrestani at apache dot org Andrew Borley ajborley at apache dot org ant elder antelder at apache dot org Brady Johnson bjohnson at apache dot org Frank Budinsky frankb at apache dot org Ignacio Silva-Lepe isilval at apache dot org Jean-Sebastien Delfino jsdelfino at apache dot org kelvin goodson kelvingoodson at apache dot org Luciano Resende lresende at apache dot org Mike Edwards edwardsmj at apache dot org Pete Robbinsrobbinspg at apache dot org Raymond Feng rfeng at apache dot org Simon Laws slaws at apache dot org Simon Nash nash at apache dot org Venkata Krishnan svkrish at apache dot org Mark Combellack mcombellack at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. +1 from me to remove the SDO reference (and Thanks for your answers and clarifications in the related DISCUSS thread [1]). However, this VOTE thread introduces other unrelated changes to the charter. Would you mind restarting a new VOTE thread for the SDO change alone? I think it'll be easier to track things if we vote on individual changes separately. Thanks. [1] http://marc.info/?t=12036982511r=1w=2 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1771) Creating JavaDoc for the integration tests listed under sca/itest folder
[ https://issues.apache.org/jira/browse/TUSCANY-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-1771. - Resolution: Fixed Patch applied under r632415. Thanks. Creating JavaDoc for the integration tests listed under sca/itest folder -- Key: TUSCANY-1771 URL: https://issues.apache.org/jira/browse/TUSCANY-1771 Project: Tuscany Issue Type: Improvement Components: Java SCA Integration Tests Affects Versions: Java-SCA-0.91 Environment: Windows XP. Java 1.5, Reporter: Naveen Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: callback-api-javadoc.patch, contribution.patch, operation-overloading.patch, properties.patch JavaDoc creation is very much necessary. JavaDoc for integration tests helps to describe the intent of the test case. JavaDoc should have details about, what exactly the test case seeks to test, verify or accomplish. It also should specify the the function of each method used in the itest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1771) Creating JavaDoc for the integration tests listed under sca/itest folder
[ https://issues.apache.org/jira/browse/TUSCANY-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1771: - Assignee: Raymond Feng (was: Venkatakrishnan) Creating JavaDoc for the integration tests listed under sca/itest folder -- Key: TUSCANY-1771 URL: https://issues.apache.org/jira/browse/TUSCANY-1771 Project: Tuscany Issue Type: Improvement Components: Java SCA Integration Tests Affects Versions: Java-SCA-0.91 Environment: Windows XP. Java 1.5, Reporter: Naveen Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: callback-api-javadoc.patch, contribution.patch, operation-overloading.patch, properties.patch JavaDoc creation is very much necessary. JavaDoc for integration tests helps to describe the intent of the test case. JavaDoc should have details about, what exactly the test case seeks to test, verify or accomplish. It also should specify the the function of each method used in the itest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1656) Memory Leaks due to XML Parser not being closed
[
https://issues.apache.org/jira/browse/TUSCANY-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-1656.
---
Resolution: Fixed
Memory Leaks due to XML Parser not being closed
---
Key: TUSCANY-1656
URL: https://issues.apache.org/jira/browse/TUSCANY-1656
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Assignee: Raymond Feng
Priority: Minor
Fix For: Java-SCA-Next
I am seeing memory leaks that appear to be a result of the StAX reader not
being explictly closed.Adding an explicit close to the reader in this
instance
eliminated my problem. Also concerned that there are other cases within the
databinding framework.
package org.apache.tuscany.sca.databinding.axiom;
import org.apache.axiom.om.OMElement;
import org.apache.tuscany.sca.databinding.impl.SimpleType2JavaTransformer;
/**
* Transformer to convert data from a simple java bject to OMElement
*/
public class OMElement2Object extends SimpleType2JavaTransformerOMElement {
@Override
protected String getText(OMElement source) {
String aText = source.getText();
try
{
source.getXMLStreamReader().close();
}
catch (Exception ex)
{}
return aText;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1646) Web Service binding doesn't handle wsdli:wsdlLocation
[ https://issues.apache.org/jira/browse/TUSCANY-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1646: - Assignee: Raymond Feng Web Service binding doesn't handle wsdli:wsdlLocation - Key: TUSCANY-1646 URL: https://issues.apache.org/jira/browse/TUSCANY-1646 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.99 Reporter: Jean-Sebastien Delfino Assignee: Raymond Feng Priority: Minor Fix For: Java-SCA-Next Attachments: diff.txt According to the Web Service binding spec, it should be possible to specify the location of the WSDL file used to configure a Web Service binding. Our WebServiceBindingProcessor is able to read that location but later ignores it and does not use it to get the the WSDL file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1711) Reference a ws with complex data type...
[ https://issues.apache.org/jira/browse/TUSCANY-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1711: - Assignee: Raymond Feng Reference a ws with complex data type... Key: TUSCANY-1711 URL: https://issues.apache.org/jira/browse/TUSCANY-1711 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: win jdk1.6 svn 575578 eclipse Reporter: gengshaoguang Assignee: Raymond Feng Fix For: Java-SCA-Next Hi every one: I have a suggestion: When a Tuscany domain references a WS provided by another (or a WS from any where). If the data type is not primitive, the consumer side must declare classes according to the data structure (or ask for stubs from the provider side). This is quite usual BUT, if we could improve a little: declare interface instead of class (respond type only), will it be more decouple mannered. Current scenario: the complex type transformation is done by: org.apache.tuscany.sca.databinding.javabeans.XML2JavaBeanTransformer it must instantiate the corresponding java type class and set values, I would suggest if the type is a interface, create a proxy. (now it gives a instantiation exception). Is this worth doing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1711) Reference a ws with complex data type...
[ https://issues.apache.org/jira/browse/TUSCANY-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573922#action_12573922 ] Raymond Feng commented on TUSCANY-1711: --- The business interfaces and data types are defined by application developers. So they should have the flexibility to choose their styles. For the java2wsdl mapping, the SCA spec says we follow the JAXWS rules. I guess in your case, the data is POJO and it uses interfaces to represent data. Are you suggesting that we use proxies to instantiate the data modeled by interfaces? Please clarify. Thanks, Raymond Reference a ws with complex data type... Key: TUSCANY-1711 URL: https://issues.apache.org/jira/browse/TUSCANY-1711 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: win jdk1.6 svn 575578 eclipse Reporter: gengshaoguang Fix For: Java-SCA-Next Hi every one: I have a suggestion: When a Tuscany domain references a WS provided by another (or a WS from any where). If the data type is not primitive, the consumer side must declare classes according to the data structure (or ask for stubs from the provider side). This is quite usual BUT, if we could improve a little: declare interface instead of class (respond type only), will it be more decouple mannered. Current scenario: the complex type transformation is done by: org.apache.tuscany.sca.databinding.javabeans.XML2JavaBeanTransformer it must instantiate the corresponding java type class and set values, I would suggest if the type is a interface, create a proxy. (now it gives a instantiation exception). Is this worth doing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1510) service name=[name] must equal to java interface name (which as @Remotable annoted)
[ https://issues.apache.org/jira/browse/TUSCANY-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1510. --- Resolution: Fixed The name match is required by the SCA spec. Now we have a meaningful warning instead of NPE. service name=[name] must equal to java interface name (which as @Remotable annoted) --- Key: TUSCANY-1510 URL: https://issues.apache.org/jira/browse/TUSCANY-1510 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: win2000 jdk1.5 Reporter: gengshaoguang Fix For: Java-SCA-Next Responding to ant elder, I raise this issue. When add service to a component, the name attribute MUST EQUAL to the java interface's name which as a @Remotable and @Service annotation, other wise there will be a NullPointer exception when initiate the SCADomain. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1449) The annotation 'Service' processor occurs error.
[ https://issues.apache.org/jira/browse/TUSCANY-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1449. --- Resolution: Fixed Patch applied. Thanks! The annotation 'Service' processor occurs error. Key: TUSCANY-1449 URL: https://issues.apache.org/jira/browse/TUSCANY-1449 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.91 Reporter: wangfeng Fix For: Java-SCA-Next Attachments: 1449.patch 1.The SCA Java Component Implementation Spec (line 21 to 121) show the annotation 'Service' value may be three ways:Java Interface,Java class,WSDL portType.But in tuscany only support Java Interface. 21 1.2.1 Service 22A component implementation based on a Java class may provide one or more services. 23The services provided by a Java-based implementation may have an interface defined in one of the 24following ways: 25 A Java interface 26 A Java class 27 A Java interface generated from a Web Services Description Language[3] (WSDL) portType 2.The SCA Java AnnotationsAndAPIs Spec (line 1635) show the annotation 'Service' can has not attributes,but the 'Service' processor in tuscany don't support this. 1635 A @Service annotation with no attributes is meaningless, it is the same as not having the annotation there 1636 at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1697) HelloWorldWSDLMergedTestCase is failing
[ https://issues.apache.org/jira/browse/TUSCANY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1697: - Assignee: Raymond Feng HelloWorldWSDLMergedTestCase is failing --- Key: TUSCANY-1697 URL: https://issues.apache.org/jira/browse/TUSCANY-1697 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.0 Reporter: ant elder Assignee: Raymond Feng Fix For: Java-SCA-Next HelloWorldWSDLMergedTestCase is failing after moving up to Axis2 1.3. For now renamed to HelloWorldWSDLMergedTestCaseFIXME so it doesn;t get run in the build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1150) Java2WSDL SchemaBuilder#isSDO can't detect static SDO and TuscanyJava2WSDLTestCase#testWsdlGeneration_SDO_Static fails to report that
[ https://issues.apache.org/jira/browse/TUSCANY-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1150: - Assignee: Raymond Feng Java2WSDL SchemaBuilder#isSDO can't detect static SDO and TuscanyJava2WSDLTestCase#testWsdlGeneration_SDO_Static fails to report that - Key: TUSCANY-1150 URL: https://issues.apache.org/jira/browse/TUSCANY-1150 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Yang ZHONG Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: 1150.patch Java2WSDL SchemaBuilder#isSDO uses DataObject.class.isAssignableFrom(staticSDOclass) to detect static SDO, but SDO generator doesn't always generate statis SDO extending DataObject.class. E.g. the very Test Case in Java2WSDL project tests against statis SDO *not* extending DataObject.class. Unfortunately, the Test Case fails to report the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-803) Association of callback methods with request methods
[ https://issues.apache.org/jira/browse/TUSCANY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-803. -- Resolution: Fixed Association of callback methods with request methods Key: TUSCANY-803 URL: https://issues.apache.org/jira/browse/TUSCANY-803 Project: Tuscany Issue Type: Improvement Components: Specification Reporter: Ignacio Silva-Lepe Assignee: Mike Edwards Fix For: Java-SCA-Next The specs (assembly and CI) do not seem to be very explicit about what should happen with an interface that is annotated as @Callback and that defines more than one method. But notice that if this is the case then the next question pertains to a previous question, which is what happens when the callback interface (the one in the annotation, not the annotated one) has more than one method. Let i1 be an intrerface annotated with @Callback(c1), where c1 is the callback interface. The simplest case is when both i1 and c1 have only one method. If i1 has 1 methods there are two cases: c1 has only one method, and c1 has 1 methods. The first case is the case at hand. Notice that one last case is where i1 has one method and c1 has 1, but that really is a special case of the second case. The second case is the one we had asked about before, how do we associate methods in c1 with methods in i1. Again, the specs are not explicit about this. In general, this association may require knowledge about the implementation of i1. That is, i1Impl will get an injected instance of c1 which then it will use in its method(s) to make callback invocations. Which c1 method is invoked in i1 is arbitrary and we may have to resort to non-trivial introspection to figure it out. Btw, nontice that this case also includes the first case. So it seems we have a choice of how to interpret the specs. 1- The simplest choice is to assume i1 and c1 both have only one method. 2- We can assume that c1 has only one method (case at hand) and introspect each method in i1 to figure out which is intended as async with callback and which is not. In addition, here we also have a choice of whether to treat non-callback methods as sync or async. 3- We can try go for the general case. My vote is to go with choice 1, which is what I have been assuming so far, at least for the coming release. And if we don't feel comfortable with this choice long term, then we can try for choice 2 or maybe even choice 3, if we can make sense of it. It would also be useful to try to go back to the spec collaboration to try to calrify the intent. More details: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg08617.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-199) Bigbank sample should use wires instead of hacked up SOAP addresses
[ https://issues.apache.org/jira/browse/TUSCANY-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-199. -- Resolution: Won't Fix Not sure if it's still valid. Bigbank sample should use wires instead of hacked up SOAP addresses --- Key: TUSCANY-199 URL: https://issues.apache.org/jira/browse/TUSCANY-199 Project: Tuscany Issue Type: Bug Components: Java SCA BigBank Sample Reporter: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-Next The bigbank sample uses a hacked up / fixed SOAP address in the WSDL to connect the external service in the webclient module component to the entry point of the account module component. This is not how it should work. One very important feature of SCA illustrated by BigBank is to allow module components to be wired together. So we should change the sample to use wires. This is how the sample is actually described in the Building your first SCA application spec companion document. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1309) NPE if SCDL uses component reference that is not defined consistently in the implementation
[
https://issues.apache.org/jira/browse/TUSCANY-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-1309.
---
Resolution: Invalid
If the reference/service under the component doesn't match what are declared
(or introspected) on the componentType, we produce a warning. In this case, the
variable is not a SCA reference and no injection happens. So it's default to
null and NPE is a user error.
NPE if SCDL uses component reference that is not defined consistently in the
implementation
---
Key: TUSCANY-1309
URL: https://issues.apache.org/jira/browse/TUSCANY-1309
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Environment: Win XP
Reporter: Simon Laws
Assignee: Jean-Sebastien Delfino
Priority: Minor
Fix For: Java-SCA-Next
For example,
public class AlertsServiceImpl {
private RSSCheckerServicerssChecker;
private AlertsSourcesService alertsSources;
@Reference
public void setRssChecker(RSSCheckerService rssChecker) {
this.rssChecker = rssChecker;
}
// missing explicit reference defintion for alertsSources.
...
}
Then the SCDL...
component name=AlertsServiceComponent
implementation.java
class=org.apache.tuscany.sca.samples.aggregator.AlertsServiceImpl /
reference name=rssChecker target=RSSCheckerComponent/
reference name=alertsSources
target=AlertsSourcesServiceComponent/
/component
Results in NPE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
[ https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12574004#action_12574004 ] Catalin Boloaja commented on TUSCANY-1997: -- Thank you very much Ant ! One question , I hope not so hard to answer. Since it's a static , this will affect any binding using Axis2 ws binding. This means that every reference pointing to a ws will have it's own connection pool with the number set by the field or is this shared inside the domain ? Axis binding does not allow external configuration to increase the number of the maximum connections opened. Key: TUSCANY-1997 URL: https://issues.apache.org/jira/browse/TUSCANY-1997 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Environment: Solaris , Windows , Websphere , Tomcat Reporter: Catalin Boloaja Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Attachments: tuscany-binding-ws-axis2-1.0-incubating-TUSCANY-1997.jar, tuscany-binding-ws-axis2-1.1-TUSCANY-1997.jar In a high volume situation the default setting for Axis2 is 2 connections per host. The default protocol being HTTP 1.1 , this means that only 2 POST requests can be issued at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Pass-by-value related SPI change
Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add boolean allowsPassByReference() to the Invoker interface directly [2] Add boolean allowsPassByReference() to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, change the Provider.createInvoker() to take InvokerProperties. Add getInvokerProperties() to the Invoker interface. [4] Define an InvokerProperties class to encapsulate known properties including allowsPassByReference, add getInvokerProperties() to the Invoker interface. [5] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, define an InvocationPropertiesFactory interface to create InvokerProperties, add getInvokerProperties() to the Invoker interface. My vote is [1], [2]. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Import/Export Resources, was Re: Resolving Component type files
I have completed the remaining work for (contribution-resource). You can now define a import.resource element in your sca-contribution.xml and then it will be used by contribution service when resolving resources/artifacts. Exporting resources using sca-contribution.xml : contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://store; xmlns:helloworld=http://store; export.resource uri=ufservices/store.html/ /contribution Importing resources using sca-contribution-xml : contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://store; xmlns:store=http://store; deployable composite=store:store/ import.resource uri=ufservices/store.html/ /contribution These definition will be used in conjunction with ArtifactModelResolver to properly resolve artifacts in different contributions using resource import/export. Please let me know if you have questions or comments. On Tue, Feb 19, 2008 at 1:20 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the new import/export resource module (contribution-resource) under revision #629235. This still need to be integrated to the runtime and proper iTests need to be created. These all should be ready in the next day or so. On Feb 18, 2008 6:35 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Do you want to restrict this to file ? Some bindings, like binding.http can point to a specific folder, that's why I thought import.resource would be more appropriate name for this new import ? You're right we need to support folders too, import.resource is better. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading code in core contribution processing
I just finished committing Import/Export resource support, more details on following thread [1]. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28457.html On Fri, Feb 29, 2008 at 11:10 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Rajini Sivaram wrote: On 2/22/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Great to see a *test* case for cycles, but my question was: Do you have a *use* case for cycles and partial packages right now or can it be fixed later? Rajini Sivaram wrote: No, I dont have an use-case, at least not an SCA one. But there are plenty of them in OSGi - eg. Tuscany modules cannot run in OSGi without support for split-packages. Of course you can fix it later. I'm not arguing for or against fixing it now or later, I'm trying to get the real use case to make a decision based on concrete grounds. Can you point me to your OSGi use cases, or help me understand Tuscany modules cannot run in OSGi without support for split packages? Tuscany node and domain code are split into three modules each for API, SPI and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl. The API module defines a set of classes in org.apache.tuscany.sca.nodeand the SPI module extends this package with more classes. So the package org.apache.tuscany.sca.node is split across tuscany-node-api and tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest entries for Tuscany modules, we would get three OSGi bundles corresponding to the node modules. And the API and SPI bundles have to specify that they use split-packages. It would obviously have been better if API and SPI used different packages, but the point I am trying to make is that splitting packages across modules is not as crazy as it sounds, and split packages do appear in code written by experienced programmers. IMO, supporting overlapping package import/exports is more important with SCA contributions than with OSGi bundles since SCA contributions can specify wildcards in import.java/export.java. eg. If you look at packaging tuscany-contribution and tuscany-contribution-impl where tuscany-contribution-impl depends on tuscany-contribution, there is no clear naming convention to separate the two modules using a single import/export statement pair. So if I could use wildcards, the simplest option that would avoid separate import/export statements for each subpackage (as required in OSGi) would be to export org.apache.tuscany.sca.contribution* from tuscany-contribution and import org.apache.tuscany.sca.contribution* in tuscany-contribution-impl. The sub-packages themselves are not shared but the import/export namespaces are. We need to avoid cycles in these cases. Again, there is a way to avoid sharing package spaces, but it is simpler to share, and there is nothing in the SCA spec which stops you sharing packages across contributions. I dont think the current model resolver code which recursively searches exporting contributions for artifacts is correct anyway - even for artifacts other than classes. IMO, when an exporting contribution is searched for an artifact, it should only search the exporting contribution itself, not its imports. And that would avoid cycles in classloading. I would still prefer not to intertwine classloading and model resolution because that would unnecessarily make classloading stack traces which are complex anyway, even more complex that it needs to be. But at least if it works all the time, rather than run into stack overflows, I might not have to look at those stack traces and this will convince me to help fix it now :) Thanks. It is not broken now - you have to break it first and then fix it :-). I have reviewed the model resolution and classloading code and found the following: - Split namespaces are currently supported (for example by the WSDL and XSD resolvers). The model resolver mechanism does not have an issue with split namespaces. - The Java import/export resolvers do not seem to support split packages (if I understood that code which was quite tricky), but that's an issue in that Java import/export specific code, which just needs to be fixed. I'll work on it. - The interactions between the Java import/export listener, the model resolvers and the ContributionClassLoader are way too complicated IMHO. That complexity is mostly caused by ContributionClassLoader, I'll try to show a simpler implementation in a few days. - Dependency cycles are an exception in Java as build tools like Maven don't support them, but can
Updating Store Tutorial to share a common ui from store-assets
Now that I finished support for Resource import/export, I was thinking on updating our Store Tutorial to share a common store.html in the tutorial-assets. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28457.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating Store Tutorial to share a common ui from store-assets
Luciano Resende wrote: Now that I finished support for Resource import/export, I was thinking on updating our Store Tutorial to share a common store.html in the tutorial-assets. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28457.html +1 from me -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
Raymond Feng wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add boolean allowsPassByReference() to the Invoker interface directly [2] Add boolean allowsPassByReference() to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, change the Provider.createInvoker() to take InvokerProperties. Add getInvokerProperties() to the Invoker interface. [4] Define an InvokerProperties class to encapsulate known properties including allowsPassByReference, add getInvokerProperties() to the Invoker interface. [5] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, define an InvocationPropertiesFactory interface to create InvokerProperties, add getInvokerProperties() to the Invoker interface. My vote is [1], [2]. Thanks, Raymond My vote is [1], [2]. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany participation at Google Summer of Code (GSoC) 2008
Apache Software Foundation is participating in Google Summer of Code program [1] as a mentoring organization. I think this is a good opportunity for us and I'd like to use this thread to discuss possible innovative and challenging projects that could attract the students participating on the program. Maybe we could start be defining some themes, and then projects around this themes, then, once we have a couple of projects, we could use wiki to create a small description of the project. Possible themes : Tuscany Extensions (new bindings and implementations) Web 2.0 Thoughts ? [1] http://code.google.com/soc/2008/ [2] http://wiki.apache.org/general/SummerOfCode2008 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Pass-by-value related SPI change
My vote is for [2], [1] Thanks - Venkat On Sat, Mar 1, 2008 at 5:14 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Please vote on one of the following five options to define allowsPassByReference property for Invokers. You can vote with multiple choices ordered by your preference. [1] Add boolean allowsPassByReference() to the Invoker interface directly [2] Add boolean allowsPassByReference() to an optional SPI (either a separate interface or a sub-interface of Invoker) [3] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, change the Provider.createInvoker() to take InvokerProperties. Add getInvokerProperties() to the Invoker interface. [4] Define an InvokerProperties class to encapsulate known properties including allowsPassByReference, add getInvokerProperties() to the Invoker interface. [5] Define an InvokerProperties interface to encapsulate known properties including allowsPassByReference, define an InvocationPropertiesFactory interface to create InvokerProperties, add getInvokerProperties() to the Invoker interface. My vote is [1], [2]. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving ServiceDiscovery and related classes to tuscany-util
Alright, I am going to create a new module named tuscany-extensibility. The reason I suggested 'util' was that there are a few more things like the 'getQName' method that is being copied over in several places. I'd like to move these things as well into this module. So lets start with 'extensibility' now. Thanks - Venkat On Fri, Feb 29, 2008 at 9:57 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? Simon Laws wrote: +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. +1 Good idea, I also like tuscany-extensibility better than a general tuscany-util bucket. ant elder wrote: Agree about moving it out of contributions but how about to avoid another new module just to a .utils package in the spi module? I think everything that needs this would already be including the tuscany-core-spi module. Please, let's not make all these modules depend on core-spi with is really a 'runtime' SPI module. This won't help anyway with circular dependencies (just make it worse) as core-spi depends on assembly, policy, contribution etc. We need to move ServiceDiscovery down one layer, not up... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
