Re: Graduation
On 9/12/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hey Ant, Thanks for bringing this up. +1 for taking this up and +1 for you being the chair. I'll dive into the graduation guide and look for things that I can help in this. - Venkat On 9/12/07, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant Ant +1 to starting the process now and you would make an excellent chair so +1 to that too. I assume everyone is going to go off and dive into the documentation (well I am). How about we put a check list up on the wiki so we all get a view of what's going on and what needs to be done by when. I've started one here by copying the checklist from the graduation guide ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Graduation+Checklist) but we need to work out what we need to do specifically for Tuscany and, of course by, when. Simon
Re: Domain changes
Thanks for the reply Sebastien A few more comments below... On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) Sounds OK to me - I'll go ahead and split them out. I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. I'm ambivalent but we have one positive request for SCANode and SCADomain so I'll wait a little longer and probably change to that host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. OK, i'll take a look at that. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Ant +1 to both! Paul On 9/12/07, Simon Laws [EMAIL PROTECTED] wrote: On 9/12/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hey Ant, Thanks for bringing this up. +1 for taking this up and +1 for you being the chair. I'll dive into the graduation guide and look for things that I can help in this. - Venkat On 9/12/07, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant Ant +1 to starting the process now and you would make an excellent chair so +1 to that too. I assume everyone is going to go off and dive into the documentation (well I am). How about we put a check list up on the wiki so we all get a view of what's going on and what needs to be done by when. I've started one here by copying the checklist from the graduation guide ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Graduation+Checklist) but we need to work out what we need to do specifically for Tuscany and, of course by, when. Simon -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: uri of binding.ws should be used restrictedly
Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant
Re: Graduation
On 12/09/2007, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) +1 We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. +1 There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for OSGi bundle contributions
Hello, Graham and I have been looking at supporting OSGi bundles as contributions in Tuscany. This is the packaging of SCA contributions as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). Unfortunately in the current Tuscany implementation, there doesn't seem to be a neat way of plugging in support for OSGi contributions. While implementation.osgi/ is a completely independent module, support for OSGi contributions would require changes to other processors. I would like to add a new module modules/contribution-osgi which provides all the code needed for supporting OSGi contribution bundles. But the code will have to be explicitly invoked from outside this module. OSGi bundles are jar files. Since there is only one processor for each contribution file type, the Jar processor will have to call OSGi bundle processor to do any special processing for OSGi bundles - the OSGi bundle processor installs the bundle into an OSGi runtime (starting a new runtime if necessary). Since class resolution for OSGi bundles should be done using OSGi resolution mechanisms rather than directly using a classloader, and there is only one resolver called by ExtensibleModelResolver for each model type, ClassReferenceModelResolver will need to call OSGiClassReferenceModelResolver to load the class using the OSGi bundle if the contribution is an OSGi bundle. The changes to JarContributionProcessor and ClassReferenceModelResolver are fairly minimal - in both cases they try to dynamically load the corresponding OSGi processor and call a method on it. All the OSGi specific code is in modules/contribution-osgi. A better solution would have been to allow multiple processors for each contribution file type and multiple resolvers for each model type, where they are called in some order until the processing is complete. But that would require more extensive changes to Tuscany. I would like your feedback on the approach to follow, and would also like to know if I should wait till 1.0 is released before submitting a patch. Thank you... Regards, Rajini
[jira] Commented: (TUSCANY-1539) The assembly model does not contain the annotated intent information
[
https://issues.apache.org/jira/browse/TUSCANY-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526711
]
Amita Vadhavkar commented on TUSCANY-1539:
--
Seems that the Intents from .composite and javaImpl.java do add under certain
conditions - one
example below. Also I have some questions about implementation intents, at the
bottom of the note.
_
e.g. impl.java
@Requires( {transaction.global})
public class CalculatorServiceImpl implements CalculatorService {
private AddService addService;
private SubtractService subtractService;
private MultiplyService multiplyService;
private DivideService divideService;
@Reference
@Requires( {transaction.local})
public void setAddService(AddService addService) {
this.addService = addService;
}
..
@Requires( {transaction.local})
public double add(double n1, double n2) {
return addService.add(n1, n2);
}
}
_
e.g. .composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
xmlns:cns=http://test;
xmlns:sns=http://test;
name=Calculator
component name=CalculatorServiceComponent
service name=CalculatorService
interface.java interface=calculator.CalculatorService /
/service
implementation.java class=calculator.CalculatorServiceImpl
requires=cns:confidentiality/
.
/component
..
/composite
_
e.g. client code
protected void setUp() throws Exception {
//Create a test embedded SCA domain
cl = getClass().getClassLoader();
domain = new EmbeddedSCADomain(cl, http://localhost;);
//Start the domain
domain.start();
// Contribute the SCA contribution
contributionService = domain.getContributionService();
File javaContribLocation = new File(./target/classes);
URL javaContribURL = javaContribLocation.toURL();
javaContribution =
contributionService.contribute(http://import-export/export-java;,
javaContribURL, false);
}
public void testIntents() throws IOException {
Composite composite =null;
for (DeployedArtifact artifact :
contributionService.getContribution(http://import-export/export-java;).getArtifacts())
{
if(artifact != null artifact.getModel() != null)
System.out.println(current
artifact:+artifact.getModel().getClass().getName());
if (artifact.getModel() instanceof Composite) {
System.out.println(URI:+artifact.getURI().toString());
if
(artifact.getURI().toString().endsWith(Calculator.composite))
{
composite = ((Composite)artifact.getModel());
break;
}
}
}
if (composite!=null)
{
System.out.println(component
name:+composite.getComponents().get(0).getName()+ services
size:+composite.getComponents().get(0).getServices().size());
System.out.println(service
:+composite.getComponents().get(0).getServices().get(0).getName());
System.out.println(service operations size:+
composite.getComponents().get(0).getServices().get(0).getInterfaceContract().getInterface().getOperations().size());
ListOperation ops =
composite.getComponents().get(0).getServices().get(0).getInterfaceContract().getInterface().getOperations();
System.out.println(service operation 0:+ops.get(0).getName());
System.out.println(service intents
size:+composite.getComponents().get(0).getServices().get(0).getRequiredIntents().size());
if(composite.getComponents().get(0).getImplementation() instanceof
JavaImplementation){
JavaImplementation javaImpl =
(JavaImplementation)composite.getComponents().get(0).getImplementation();
if(javaImpl instanceof IntentAttachPoint){
IntentAttachPoint javaImplIntentAttachPoint =
(IntentAttachPoint)javaImpl;
ListIntent intents =
javaImplIntentAttachPoint.getRequiredIntents();
System.out.println(Impl Intents SIZE:+intents.size());
if(intents.size() == 4){
System.out.println(RESULT intent
0:+intents.get(0).getName());
System.out.println(RESULT intent
1:+intents.get(1).getName());
System.out.println(RESULT intent
[jira] Updated: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
[ https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1561: --- Attachment: axis2-1.2-to-1.3.diff Axis2 1.3 patch that gets all the tests passing and a successful build Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-1.0 Attachments: 1561-java.diff, 1561.patch, axis2-1.2-to-1.3.diff Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. -- 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: Fwd: uri of binding.ws should be used restrictedly
Hi, Ant, I just think respected code is ok, uri is just from osoa's specification. The theory is convenient, but the fact is not (web service is some thing good but too loosely coupled). ant elder [EMAIL PROTECTED] wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant -- Forwarded message -- From: ant elder Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng wrote: Hello every one, uri attribute of is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant - Don't let your dream ride pass you by.Make it a reality with Yahoo! Autos.
Re: Java2WSDL output for no parameters or void return type?
I am not quite clear about the intended changes in the Axis2 generator
in the future. There were two different cases described, with only
one answer. Please see my comments inline.
Simon (Nash)
Simon Laws wrote:
Thanks for the reply Deepal. So we can assume that in some future version of
Axis2 running java2wsdl on the method
public String foo();
Will give rise to the types
+xs:element name=foo
+ xs:complexType/
+ /xs:element
xs:element name=fooResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
If we know this is the intention we can code accordingly in Tuscany, i.e.
potentially post process the WSDL definition for now to add in the missing
type.
This would resolve the first question about a method for an in-out MEP that
has no parameters.
Regards
Simon
On 9/12/07, Deepal Jayasinghe [EMAIL PROTECTED] wrote:
On 9/12/07, Simon Laws [EMAIL PROTECTED] wrote:
Hi
I asked this question on the user list but would like to move it along
and ask the developer communities opinion
In the Apache Tuscany Incubator we are using the Axis2 Java2WSDL
tooling. We generate document/literal/wrapped wsdl (the default I believe
for java2WSDL) and in Tuscany we are using the JAX-WS V2 specification as a
guide to what constitutes wrapped WSDL. We are coming up to our 1.0release (in
a few weeks time) and have run into a couple of issues where we
need to decide quickly whether we are using the Axis2 tools incorrectly or
whether we need to implement a work around.
Note. We are running with Axis2 1.2 in Tuscany currently but I did the
generation below with Axis2 1.3 just to see if anything had changed in
the latest version.
For the interface:
public interface TestServiceParam {
public String foo();
}
Axis1.3 Java2WSDL produces
...
wsdl:types
xs:schema xmlns:ns= http://test;
attributeFormDefault=qualified elementFormDefault=qualified
targetNamespace= http://test;
xs:element name=fooResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=fooRequest/
wsdl:message name=fooResponse
wsdl:part name=parameters element=ns0:fooResponse/
/wsdl:message
wsdl:portType name=TestServiceParamPortType
wsdl:operation name=foo
wsdl:input message=ns0:fooRequest wsaw:Action=urn:foo/
wsdl:output message=ns0:fooResponse
wsaw:Action=urn:fooResponse/
/wsdl:operation
/wsdl:portType
...
I was expecting the following. I've added + to the lines that have been
added.
...
wsdl:types
xs:schema xmlns:ns= http://test;
attributeFormDefault=qualified elementFormDefault=qualified
targetNamespace= http://test;
+xs:element name=foo
+ xs:complexType/
+ /xs:element
xs:element name=fooResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=fooRequest
+wsdl:part name=parameters element=ns0:foo/
/wsdl:message
wsdl:message name=fooResponse
wsdl:part name=parameters element=ns0:fooResponse/
/wsdl:message
wsdl:portType name=TestServiceParamPortType
wsdl:operation name=foo
wsdl:input message=ns0:fooRequest wsaw:Action=urn:foo/
wsdl:output message=ns0:fooResponse
wsaw:Action=urn:fooResponse/
/wsdl:operation
/wsdl:portType
...
Is the current output produced by design and if so why is it this way?
Are there options I can use to make java2WSDL generate the form I would
like?
For the interface
public interface TestServiceReturn {
public void foo(String param);
}
Axis1.3 Java2WSDL produces
wsdl:types
xs:schema xmlns:ns= http://test;
attributeFormDefault=qualified elementFormDefault=qualified
targetNamespace= http://test;
xs:element name=foo
xs:complexType
xs:sequence
xs:element minOccurs=0 name=param0
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=fooRequest
wsdl:part name=parameters element=ns0:foo/
/wsdl:message
wsdl:portType name=TestServiceReturnPortType
wsdl:operation name=foo
wsdl:input message=ns0:fooRequest wsaw:Action=urn:foo/
/wsdl:operation
Re: Java2WSDL output for no parameters or void return type?
shaoguang geng wrote:
Hi Simon,
Did I understand you well:
2 way and 1 way is by differences of input parameter?
If you mean this, my suggestion would be: usually developers design WS as query/response. This has
been a usual. To support query only and response only WS is not really
important for Tuscany.
For an SCA method that's marked @OneWay, I think a one-way MEP (query only)
would be the right mapping to WSDL. For methods not marked @OneWay, I would
expect a two-way MEP (query/response). I don't see a use case in SCA
for a response-only MEP.
Simon
Simon Laws [EMAIL PROTECTED] wrote: Hi
I asked this question on the user list but would like to move it along and
ask the developer communities opinion
In the Apache Tuscany Incubator we are using the Axis2 Java2WSDL tooling. We
generate document/literal/wrapped wsdl (the default I believe for java2WSDL)
and in Tuscany we are using the JAX-WS V2 specification as a guide to what
constitutes wrapped WSDL. We are coming up to our 1.0 release (in a few
weeks time) and have run into a couple of issues where we need to decide
quickly whether we are using the Axis2 tools incorrectly or whether we need
to implement a work around.
Note. We are running with Axis2 1.2 in Tuscany currently but I did the
generation below with Axis2 1.3 just to see if anything had changed in the
latest version.
For the interface:
public interface TestServiceParam {
public String foo();
}
Axis1.3 Java2WSDL produces
...
elementFormDefault=qualified targetNamespace= http://test;
nillable=true type=xs:string/
wsaw:Action=urn:fooResponse/
...
I was expecting the following. I've added + to the lines that have been
added.
...
elementFormDefault=qualified targetNamespace= http://test;
+
+
+
nillable=true type=xs:string/
+
wsaw:Action=urn:fooResponse/
...
Is the current output produced by design and if so why is it this way?
Are there options I can use to make java2WSDL generate the form I would
like?
For the interface
public interface TestServiceReturn {
public void foo(String param);
}
Axis1.3 Java2WSDL produces
elementFormDefault=qualified targetNamespace= http://test;
nillable=true type=xs:string/
How did Axis2 decide to produce a one way message here?
Is there a way I can ask java2WSDL to produce a 2 way message in this
situation?
I've looked in the mail lists and in JIRA and I don't see mention of this
but I'm fairly new to the resources that Axis2 has to offer so there's a
good chance I'm not looking in the right place or with the right search
term. Apologies if it's staring me in the face.
Thanks
Simon Laws
Apache Tuscany Incubator
-
Building a website is a piece of cake.
Yahoo! Small Business gives you all the tools to get online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
I'm pleased to see this being discussed. I'd like to see Tuscany graduate from the incubator, and I think we're ready to take this step. +1 (non-binding) for Ant as chair. Simon kelvin goodson wrote: On 12/09/2007, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) +1 We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. +1 There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain changes
Comments inline. Simon Simon Laws wrote: Thanks for the reply Sebastien A few more comments below... On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) Sounds OK to me - I'll go ahead and split them out. I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. I'm ambivalent but we have one positive request for SCANode and SCADomain so I'll wait a little longer and probably change to that I don't think we need SCA in front of these names. After all, just about everything we are doing in Tuscany is to do with SCA, so if we go down this path we might see SCA name prefixes cropping up everywhere :-( Is there a reason why these two names would need SCA in front of them? Do we have any other Node or Domain concept in Tuscany that could be be confused with these? host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. OK, i'll take a look at that. + 1 for this. I think the new module should include the API for creating a domain as well. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
Thanks for doing this work and posting the complete list of changes needed. I just have one question about these changes. Why are the contents of HelloWorldWSDLMergedTestCase.java commented out? Simon ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1561: --- Attachment: axis2-1.2-to-1.3.diff Axis2 1.3 patch that gets all the tests passing and a successful build Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-1.0 Attachments: 1561-java.diff, 1561.patch, axis2-1.2-to-1.3.diff Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain changes
On 9/12/07, Simon Nash [EMAIL PROTECTED] wrote: Comments inline. Simon Simon Laws wrote: Thanks for the reply Sebastien A few more comments below... On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) Sounds OK to me - I'll go ahead and split them out. I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. I'm ambivalent but we have one positive request for SCANode and SCADomain so I'll wait a little longer and probably change to that I don't think we need SCA in front of these names. After all, just about everything we are doing in Tuscany is to do with SCA, so if we go down this path we might see SCA name prefixes cropping up everywhere :-( Is there a reason why these two names would need SCA in front of them? Do we have any other Node or Domain concept in Tuscany that could be be confused with these? host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. OK, i'll take a look at that. + 1 for this. I think the new module should include the API for creating a domain as well. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I don't think we have more than one node or domain concept. These words are used elsewhere many times (outside of Tuscany) and it could be useful to ensure that people understand that we are talking about the Tuscany concept of Node and Domain rather than anyone else's. The code at the moment uses Node and Domain. I raised the question as I felt
Re: [jira] Updated: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
That would be a mistake :) I'll go uncomment them. ...ant On 9/12/07, Simon Nash [EMAIL PROTECTED] wrote: Thanks for doing this work and posting the complete list of changes needed. I just have one question about these changes. Why are the contents of HelloWorldWSDLMergedTestCase.java commented out? Simon ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] ant elder updated TUSCANY-1561: --- Attachment: axis2-1.2-to-1.3.diff Axis2 1.3 patch that gets all the tests passing and a successful build Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-1.0 Attachments: 1561-java.diff, 1561.patch, axis2-1.2-to-1.3.diff Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: uri of binding.ws should be used restrictedly
Hi, as far as I recollect there was a discussion around this(am still trying to pull that thread out) and the exception was intentionally pulled out. I guess a WARNING is something that we must throw at the least. - Venkat On 9/12/07, ant elder [EMAIL PROTECTED] wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant
Re: Including the SCA spec XSDs in the Tuscany distribution?
Folks, ant elder wrote: It would be interesting to know if the license will be changed to something more standard with the move to OASIS. The license will change, for sure, since OASIS has its own rules about these things. What exactly it will look like is one of the chores that I will have to deal with soon However, that change won't be for a while, since the OASIS TCs will have to approve publication of an OASIS version of the spec and the other artifacts. So don't hold your breath. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain changes
Simon Laws wrote: On 9/12/07, Simon Nash [EMAIL PROTECTED] wrote: (cut) I don't think we have more than one node or domain concept. These words are used elsewhere many times (outside of Tuscany) and it could be useful to ensure that people understand that we are talking about the Tuscany concept of Node and Domain rather than anyone else's. The code at the moment uses Node and Domain. I raised the question as I felt there was scope for confusion. I'm now thinking that the SCA prefix is too loose (and not applicable in the Node code) so maybe TuscanyNode/TuscanyDomain would fit the bill? I think this is better. I would see the TuscanyDomain as Tuscany's implementation of SCA's Domain concept. In that correct? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1682) DataBindingRuntimeWireProcessor bug in processing boundary condition of no-arg, no-returnType method
[
https://issues.apache.org/jira/browse/TUSCANY-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526749
]
Simon Nash commented on TUSCANY-1682:
-
This issue is marked patch available but I don't see an attachment :-) The
good news is that I have a patch for this. I will verify it on the latest
trunk code and attach it shortly.
DataBindingRuntimeWireProcessor bug in processing boundary condition of
no-arg, no-returnType method
-
Key: TUSCANY-1682
URL: https://issues.apache.org/jira/browse/TUSCANY-1682
Project: Tuscany
Issue Type: Bug
Reporter: Scott Kurz
Assignee: Raymond Feng
If I have a Java method like:
void myMethod()
it will fail if I expose this method over something like the WS binding which
results in trying to set up the Tuscany databinding framework mapping the
equivalent WSDL to the no-arg, no-return method.
The exception looks like:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:572)
at java.util.ArrayList.get(ArrayList.java:347)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:97)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:115)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.process(DataBindingRuntimeWireProcessor.java:132)
at
org.apache.tuscany.sca.core.invocation.ExtensibleWireProcessor.process(ExtensibleWireProcessor.java:40)
For my failure,
The logical of the source DataType is:
[class java.lang.Object org.apache.axiom.om.OMElement Element:
{http://basicapp}doNonBlockingReq Type: null]
The logical of the target DataType is:
[] (empty array)
Now.. on the one hand this is a low-priority since this isn't a very useful
service operation.
On the other hand, the only reason we don't have the same problem on a
method like:MyReturnType myMethod()
is because for something like the WS binding, the output types will be
compared first, and this comparison will return 'true', causing the input
types not to be compared.
Some sort of special-case (possibly involving recognizing that this is
wrapped?) seems to be needed.
--
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: NPE in HTTPLocationBasedDispatcher binding-ws-axis2
You should be able to comment out the HTTPLocationBasedDispatcher as the TuscanyDispatcher should be picking up all the Tuscany services. ...ant On 9/11/07, Dinesh Shahane [EMAIL PROTECTED] wrote: I have locally modified binding-ws-axis2 for supporting SOAP/JMS. The axis2.xml file included with this binding has HTTPLocationBasedDispatcher configured in the inflow. I have noticed that this dispatcher throws a NPE for SOAP/JMS services on the following line String uri = messageContext.getTo().getAddress(); Please suggest if we need this dispatcher? Somewhere on Axis2 list I saw a suggestion to comment it out and I was wondering if it is going to break any functionality in SOAP/HTTP services. Following is the message context - ?xml version='1.0' encoding='utf-8'? soapenv:Envelope xmlns:wsa=http://www.w3.org/2005/08/addressing; xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ soapenv:Header wsa:Tojms:/queue.foo?transport.jms.ConnectionFactoryJNDIName=QueueConnecti onFactoryamp;java.naming.factory.initial... /wsa:To wsa:MessageIDurn:uuid:9C87769C7F8C63F2F31189496132078/wsa:MessageID wsa:Action/wsa:Action /soapenv:Header soapenv:Body hello:getGreetings xmlns:hello=http://helloworld; hello:nameTuscany/hello:name /hello:getGreetings /soapenv:Body /soapenv:Envelope
Re: Support for OSGi bundle contributions
If you can get a patch together that you're comfortable with by tomorrow then I'd say go for it. But we plan to take the 1.0 branch on Friday so if its much later then then it probably will have to miss 1.0. ...ant On 9/12/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, Graham and I have been looking at supporting OSGi bundles as contributions in Tuscany. This is the packaging of SCA contributions as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). Unfortunately in the current Tuscany implementation, there doesn't seem to be a neat way of plugging in support for OSGi contributions. While implementation.osgi/ is a completely independent module, support for OSGi contributions would require changes to other processors. I would like to add a new module modules/contribution-osgi which provides all the code needed for supporting OSGi contribution bundles. But the code will have to be explicitly invoked from outside this module. OSGi bundles are jar files. Since there is only one processor for each contribution file type, the Jar processor will have to call OSGi bundle processor to do any special processing for OSGi bundles - the OSGi bundle processor installs the bundle into an OSGi runtime (starting a new runtime if necessary). Since class resolution for OSGi bundles should be done using OSGi resolution mechanisms rather than directly using a classloader, and there is only one resolver called by ExtensibleModelResolver for each model type, ClassReferenceModelResolver will need to call OSGiClassReferenceModelResolver to load the class using the OSGi bundle if the contribution is an OSGi bundle. The changes to JarContributionProcessor and ClassReferenceModelResolver are fairly minimal - in both cases they try to dynamically load the corresponding OSGi processor and call a method on it. All the OSGi specific code is in modules/contribution-osgi. A better solution would have been to allow multiple processors for each contribution file type and multiple resolvers for each model type, where they are called in some order until the processing is complete. But that would require more extensive changes to Tuscany. I would like your feedback on the approach to follow, and would also like to know if I should wait till 1.0 is released before submitting a patch. Thank you... Regards, Rajini
websphere web service deployment problem
Hi all, We having problems deploying our services to Websphere. We have resolved some WAS classloading issues as was recommended by ant elder on the user group, it seems that the initialization is without a problem now. But the URL we are trying to map, e.g. http://localhost:9201/contextRoot/componentName/serviceName?wsdl is not returning anything. Is there anybody in Tuscany team who has tried deployment to Websphere? The same WAR file seems to be working fine on Tomcat, however, not in WAS 6.1. Thanks, Radim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java2WSDL output for no parameters or void return type?
Il giorno mar, 11/09/2007 alle 18.11 -0700, shaoguang geng ha scritto: Hi Simon, Did I understand you well: 2 way and 1 way is by differences of input parameter? If you mean this, my suggestion would be: usually developers design WS as query/response. This has been a usual. To support query only and response only WS is not really important for Tuscany. I disagree, how do you realize @OneWay annotation? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
ant elder wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant +1 to both, we need to start working on the proposal, and you'll make an excellent chair! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: uri of binding.ws should be used restrictedly
Mike Edwards wrote: Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins silently in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. WSDL becomes delicate - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant Having the WSDL win is as per the spec. +1 to log a [WARNING]. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
+1 to both, thanks Ant. On 9/11/07, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant
Re: Graduation
Completely +1 for both proposals! Andy On 9/12/07, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: +1 to both, thanks Ant. On 9/11/07, ant elder [EMAIL PROTECTED] wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution , we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain changes
Simon Nash wrote: Simon Laws wrote: On 9/12/07, Simon Nash [EMAIL PROTECTED] wrote: (cut) I don't think we have more than one node or domain concept. These words are used elsewhere many times (outside of Tuscany) and it could be useful to ensure that people understand that we are talking about the Tuscany concept of Node and Domain rather than anyone else's. The code at the moment uses Node and Domain. I raised the question as I felt there was scope for confusion. I'm now thinking that the SCA prefix is too loose (and not applicable in the Node code) so maybe TuscanyNode/TuscanyDomain would fit the bill? I think this is better. I would see the TuscanyDomain as Tuscany's implementation of SCA's Domain concept. In that correct? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So I thought a little bit more about that and I think I prefer: org.apache.tuscany.sca.Domain instead of: org.apache.tuscany.sca.SCADomain or org.apache.tuscany.sca.TuscanyDomain. This is similar to: org.osoa.sca.ComponentContext org.osoa.sca.ServiceReference commonj.sdo.DataObject which are not named: org.osoa.sca.SCAComponentContext org.osoa.sca.SCAServiceReference commonj.sdo.SDODataObject -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1682) DataBindingRuntimeWireProcessor bug in processing boundary condition of no-arg, no-returnType method
[
https://issues.apache.org/jira/browse/TUSCANY-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-1682.
---
Resolution: Fixed
I checked in a fix under 574648. Sorry, it's buried in a lot of changes.
DataBindingRuntimeWireProcessor bug in processing boundary condition of
no-arg, no-returnType method
-
Key: TUSCANY-1682
URL: https://issues.apache.org/jira/browse/TUSCANY-1682
Project: Tuscany
Issue Type: Bug
Reporter: Scott Kurz
Assignee: Raymond Feng
If I have a Java method like:
void myMethod()
it will fail if I expose this method over something like the WS binding which
results in trying to set up the Tuscany databinding framework mapping the
equivalent WSDL to the no-arg, no-return method.
The exception looks like:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:572)
at java.util.ArrayList.get(ArrayList.java:347)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:97)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:115)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.process(DataBindingRuntimeWireProcessor.java:132)
at
org.apache.tuscany.sca.core.invocation.ExtensibleWireProcessor.process(ExtensibleWireProcessor.java:40)
For my failure,
The logical of the source DataType is:
[class java.lang.Object org.apache.axiom.om.OMElement Element:
{http://basicapp}doNonBlockingReq Type: null]
The logical of the target DataType is:
[] (empty array)
Now.. on the one hand this is a low-priority since this isn't a very useful
service operation.
On the other hand, the only reason we don't have the same problem on a
method like:MyReturnType myMethod()
is because for something like the WS binding, the output types will be
compared first, and this comparison will return 'true', causing the input
types not to be compared.
Some sort of special-case (possibly involving recognizing that this is
wrapped?) seems to be needed.
--
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: Graduation
Finally :-). +1 on both proposals. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, September 11, 2007 4:50 PM Subject: Graduation So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: uri of binding.ws should be used restrictedly
On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Mike Edwards wrote: Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins silently in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. WSDL becomes delicate - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant Having the WSDL win is as per the spec. The spec doesn't clearly define what to do in this exact situation, I think thats a bug in the spec. And it doesn't seem very user friendly to just ignore a users input whether or not we give a warning as thats likely to just get buried in a log somewhere, so i'd prefer and exception. Isn't that what we agreed last time this came up - http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser. ...ant
Re: Graduation
Completely +1 for both proposals, as Simon Nash said, I'd like to see Tuscany graduate from the incubator, and I think we're ready to take this step. On 9/12/07, Raymond Feng [EMAIL PROTECTED] wrote: Finally :-). +1 on both proposals. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Tuesday, September 11, 2007 4:50 PM Subject: Graduation So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Domain changes
Jean-Sebastien Delfino wrote: Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. Simon On top of what you already have, I'd like to be able to describe Nodes with something like follows: composite name=MyNodes component name=NodeA implementation.node composite=bb:BigbankAccount/ /component component name=NodeB implementation.node composite=bb:BigbankCalculator/ /component /composite allowing, as a next step, to do something like follows: composite name=MyNodes component name=NodeA service name=ContributionManager binding.ws/ /service service name=ComponentManager binding.ws/ /service implementation.node composite=bb:BigbankAccount/ /component or for example component name=NodeB service name=ContributionManager binding.atom/ /service service name=ComponentManager binding.jsonrpc/ /service implementation.node composite=bb:BigbankCalculator/ /component /composite I'm starting on working on an implementation-node module to support that. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for OSGi bundle contributions
Some comments online... On 9/12/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, Graham and I have been looking at supporting OSGi bundles as contributions in Tuscany. This is the packaging of SCA contributions as OSGi bundles where OSGi will bring modularity and versioning to SCA. Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in implementation.java/ and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). Unfortunately in the current Tuscany implementation, there doesn't seem to be a neat way of plugging in support for OSGi contributions. While implementation.osgi/ is a completely independent module, support for OSGi contributions would require changes to other processors. I would like to add a new module modules/contribution-osgi which provides all the code needed for supporting OSGi contribution bundles. But the code will have to be explicitly invoked from outside this module. OSGi bundles are jar files. Since there is only one processor for each contribution file type, the Jar processor will have to call OSGi bundle processor to do any special processing for OSGi bundles - the OSGi bundle processor installs the bundle into an OSGi runtime (starting a new runtime if necessary). So, isn't this the case where you could identify that the jar being processed is a OSGI bundle, and call a OSGI processor directly, instead of making the jar processor delegating ? Since class resolution for OSGi bundles should be done using OSGi resolution mechanisms rather than directly using a classloader, and there is only one resolver called by ExtensibleModelResolver for each model type, ClassReferenceModelResolver will need to call OSGiClassReferenceModelResolver to load the class using the OSGi bundle if the contribution is an OSGi bundle. Maybe we need to extend the packageProcessor to influence more what type of resolution and loading mechanisms to be used The changes to JarContributionProcessor and ClassReferenceModelResolver are fairly minimal - in both cases they try to dynamically load the corresponding OSGi processor and call a method on it. All the OSGi specific code is in modules/contribution-osgi. A better solution would have been to allow multiple processors for each contribution file type and multiple resolvers for each model type, where they are called in some order until the processing is complete. But that would require more extensive changes to Tuscany. I'll wait to see a patch to better comment on your proposal. I would like your feedback on the approach to follow, and would also like to know if I should wait till 1.0 is released before submitting a patch. Thank you... Regards, Rajini -- 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: Fwd: uri of binding.ws should be used restrictedly
ant elder wrote: On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Mike Edwards wrote: Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins silently in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. WSDL becomes delicate - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant Having the WSDL win is as per the spec. Here's from the SCA Web Services Binding spec: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification The spec doesn't clearly define what to do in this exact situation, I think thats a bug in the spec. What's not clear? What's the bug in the spec? And it doesn't seem very user friendly to just ignore a users input whether or not we give a warning as thats likely to just get buried in a log somewhere, so i'd prefer and exception. Forcing the application developer to modify the binding.ws and remove the uri attribute, to be able to specify the SOAP address in his WSDL is not user friendly either, and not in line with the spec. Isn't that what we agreed last time this came up - http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser. This points to the whole July archive :) ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Folks, +1. +1. Can we start to identify work tasks to get us there and then start to parcel out work amongst folk on the project? Yours, Mike. ant elder wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA. We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: uri of binding.ws should be used restrictedly
On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Mike Edwards wrote: Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins silently in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. WSDL becomes delicate - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant Having the WSDL win is as per the spec. Here's from the SCA Web Services Binding spec: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification The spec doesn't clearly define what to do in this exact situation, I think thats a bug in the spec. What's not clear? The same thing as why it goes on in line 84/85 to say you can't have an EPR and wsdlElement port together What's the bug in the spec? Line 84/85 should continue on to say what to do about when you specify a uri attribute together with a wsdl port or EPR. And it doesn't seem very user friendly to just ignore a users input whether or not we give a warning as thats likely to just get buried in a log somewhere, so i'd prefer and exception. Forcing the application developer to modify the binding.ws and remove the uri attribute, to be able to specify the SOAP address in his WSDL is not user friendly either, and not in line with the spec. I just don't see that as a very common thing to want to be doing. Isn't that what we agreed last time this came up - http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser . This points to the whole
Re: Build error with WSSecurityConfidentialityTestCase
Venkata Krishnan wrote: Hi Sebastien, There is nothing that needs to be done in the environment. The only dependency that I had trouble linking to the classpath from the maven repo during a maven build is the rampart.mar which I have now temporarilty packaged with the module. I suspect it could be to do with the key store and the JDK version you are using. Could you please try creating it with the following command: *keytool -genkey -alias TuscanyWsUser -keyalg RSA -keystore tuscanyKeys.jks * All thro, for everthing there is just one password I have used and it is 'TuscanyWsUserPasswd' and there is just one user id which is TuscanyWsUser. I created the key with keytool. The build is successful with the SUN JDK 1.5, getting the exception below with the IBM JDK 1.5. - Venkat On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Is anybody else seeing that build error? Do I need to set up anything new in my build environment now that we have WS-security enabled (which is pretty cool BTW)? Running org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Sep 11, 2007 7:04:02 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://localhost:8085/myExplicitURI *** Calling Integrity Password Handler Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.096 sec FAILURE! testHelloWorld( org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase ) Time elapsed: 3.04 sec ERROR! java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:214) at javax.crypto.KeyGenerator.a(Unknown Source) at javax.crypto.KeyGenerator.init(Unknown Source) at javax.crypto.KeyGenerator.getInstance(Unknown Source) at org.apache.ws.security.message.WSSecEncrypt.getKeyGenerator( WSSecEncrypt.java:578) at org.apache.ws.security.message.WSSecEncrypt.prepare(WSSecEncrypt.java:202) at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:268) at org.apache.ws.security.action.EncryptionAction.execute( EncryptionAction.java:62) at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java :192) at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java :256) at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java :88) at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72) at org.apache.axis2.engine.Phase.invoke(Phase.java:383) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:433) at org.apache.axis2.description.OutInAxisOperationClient.send( OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute( OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget( Axis2BindingInvoker.java:95) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke (DataTransformationInteceptor.java:70) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldOMComponent.getGreetings (HelloWorldOMComponent.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :64) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:105) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInteceptor.invoke( PassByValueInteceptor.java:49) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.policy.AbstractHelloWorldOMTestCase.testHelloWorld (AbstractHelloWorldOMTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
[jira] Created: (TUSCANY-1688) XSD2JavaGenerator throws IOException:Access is denied with complexType named Con
XSD2JavaGenerator throws IOException:Access is denied with complexType named Con -- Key: TUSCANY-1688 URL: https://issues.apache.org/jira/browse/TUSCANY-1688 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-Next Environment: Windows XP SP2 w/Sun JDK 1.4.2_11 Reporter: Ron Gavlin I have an XML Schema that contains a complexType named Con. The following error output is displayed to stdout: Generating Con Generating Java interface test.Con Generating /TargetProject/test/Con.java Examining old /TargetProject/test/Con.java org.eclipse.emf.common.util.WrappedException: java.io.IOException: Access is denied at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava (AbstractGeneratorAdapter.java:1046) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateInterface (GenClassGeneratorAdapter.java:123) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenClassGeneratorAdapter.generateModel (GenClassGeneratorAdapter.java:106) at org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate (GenBaseGeneratorAdapter.java:214) at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate (AbstractGeneratorAdapter.java:275) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:600) at org.eclipse.emf.codegen.ecore.generator.Generator.generate (Generator.java:512) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel (JavaGenerator.java:515) ... It seems as if the type name 'Con' conflicts with the operating system's console device named 'Con'. The code first checks to see if the file exists to decide if a merge is required. The code seems to incorrectly find the file/device named 'Con' and then tries to access it in error. I suspect this is an Eclipse EMF problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1689) XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType named Descriptor
XSD2JavaGenerator generates non-compilable FactoryImpl class with complexType
named Descriptor
Key: TUSCANY-1689
URL: https://issues.apache.org/jira/browse/TUSCANY-1689
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Environment: Windows XP SP2 w/Sun JDK 1.4.2_11
Reporter: Ron Gavlin
Fix For: Java-SDO-Next
I have a schema with a complexType named Descriptor.
The generated FactoryImpl.java class includes the following code which does not
compile because the return type org.eclipse.emf.ecore.EPackage.Descriptor is
not compatible with Factory.createDescriptor() with return type
myNamespace.Descriptor:
public Descriptor createDescriptor()
{
DescriptorImpl descriptor = new DescriptorImpl();
return descriptor;
}
I suspect this is an EMF bug but I am reporting it here.
--
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-1690) Support SCA domain level autowire
Support SCA domain level autowire -- Key: TUSCANY-1690 URL: https://issues.apache.org/jira/browse/TUSCANY-1690 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng At this moment, we support autowire in the local composite. We need to add it for the domain-level too. -- 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-1505) Naming scheme used for variables in code gen factory init() method breaks under specific circumstances
[ https://issues.apache.org/jira/browse/TUSCANY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo resolved TUSCANY-1505. - Resolution: Fixed Fixes in revision 575081 Naming scheme used for variables in code gen factory init() method breaks under specific circumstances -- Key: TUSCANY-1505 URL: https://issues.apache.org/jira/browse/TUSCANY-1505 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0 Environment: n/a Reporter: David T. Adcox Priority: Minor Fix For: Java-SDO-Next Attachments: 1505.patch, 1505.patch, test1505.zip A new code gen pattern was recently added to change how dependent packages are initialized in the xxxFactoryImpl.init() method. Under this new pattern, all dependent packages are initialized via the factoryInterface.INSTANCE method. An initialization call is made for each dependent gen package. The getImportedFactoryInterfaceName() is used to retrieve the short name. This value is mashed with the text 'Instnace' to form a variable name. If circumstances dictate that multiple packages contain the same factory interface name, the getImportedFactoryInterfaceName() will fully qualify the response instead of using the short name. This breaks the generated code, due to the use of a '.' in the variable name. -- 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: websphere web service deployment problem
I assume you did all the following correct: - I assume the context root is correct for the war: you can use WAS console to check the value - I assume the port is correct. E.g. in my env, 9081 is the default port for my war. You can also use WAS console to check the setting on virtualHost - I assume the componentName/ServiceName is the one you registered to Axis 2 engine? Can you do the following to make sure Axis 2 recognize the service? http://localhost:9201/contextRoot/componentName/serviceName if you can then you can try http://localhost:9201/contextRoot/componentName/serviceName/?wsdl Good luck. Yang. On 9/12/07, Radim Kolarik [EMAIL PROTECTED] wrote: Hi all, We having problems deploying our services to Websphere. We have resolved some WAS classloading issues as was recommended by ant elder on the user group, it seems that the initialization is without a problem now. But the URL we are trying to map, e.g. http://localhost:9201/contextRoot/componentName/serviceName?wsdl is not returning anything. Is there anybody in Tuscany team who has tried deployment to Websphere? The same WAR file seems to be working fine on Tomcat, however, not in WAS 6.1. Thanks, Radim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1673) PackageClassInfo being override when Element and ComplexType have same name
[ https://issues.apache.org/jira/browse/TUSCANY-1673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1673: Attachment: 1673.patch It seems WSDL2Java is dependent on the info from the XSD2JavaGenerator that would key on the global elements so it can build TypeMapper to resolve parameter types of the service interfaces during the wsdl2java codegen. I have tested building wsdl2java project and it seems working now. PackageClassInfo being override when Element and ComplexType have same name --- Key: TUSCANY-1673 URL: https://issues.apache.org/jira/browse/TUSCANY-1673 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-Next Reporter: Luciano Resende Priority: Blocker Fix For: Java-SDO-Next Attachments: 1673.patch, 1673.patch, interopdoc.wsdl In Wsdl2Java, interfaces are getting generated wrong, because isAnonymous information is getting overridden when element and complexType have same name. I'll attach the wsdl in question here. -- 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-1686) Cannot throw business exceptions across the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-1686: --- Assignee: Simon Nash Cannot throw business exceptions across the Web Service binding --- Key: TUSCANY-1686 URL: https://issues.apache.org/jira/browse/TUSCANY-1686 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Priority: Blocker Fix For: Java-SCA-1.0 Attachments: jira1686.zip I tried to throw a very simple business exception across the Web Service binding. My test case is using explicit WSDL that was generated by Axis2 1.3 and I have verified that it is correct. Here's the error that I got: Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.535 sec FAILURE! test(com.example.ExampleTestCase) Time elapsed: 3.505 sec ERROR! java.lang.reflect.UndeclaredThrowableException at $Proxy8.hello(Unknown Source) at com.example.ExampleClientImpl.runTest(ExampleClientImpl.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:105) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:128) at $Proxy7.runTest(Unknown Source) at com.example.ExampleTestCase.test(ExampleTestCase.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:244) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:814) Caused by: org.apache.axis2.AxisFault: org.apache.tuscany.sca.databinding.TransformationException: No matching source fault type is found at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:434) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:373) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:95) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:70) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:128) ... 34 more -- This
[jira] Commented: (TUSCANY-1686) Cannot throw business exceptions across the Web Service binding
[ https://issues.apache.org/jira/browse/TUSCANY-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526939 ] Simon Nash commented on TUSCANY-1686: - I have been successful in getting a simple business exception to flow end to end over the Web Service binding. I'll clean up the code and post a patch tomorrow (Thursday). There are changes in binding-ws-axis2 and core-databinding. Cannot throw business exceptions across the Web Service binding --- Key: TUSCANY-1686 URL: https://issues.apache.org/jira/browse/TUSCANY-1686 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Priority: Blocker Fix For: Java-SCA-1.0 Attachments: jira1686.zip I tried to throw a very simple business exception across the Web Service binding. My test case is using explicit WSDL that was generated by Axis2 1.3 and I have verified that it is correct. Here's the error that I got: Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.535 sec FAILURE! test(com.example.ExampleTestCase) Time elapsed: 3.505 sec ERROR! java.lang.reflect.UndeclaredThrowableException at $Proxy8.hello(Unknown Source) at com.example.ExampleClientImpl.runTest(ExampleClientImpl.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:105) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:128) at $Proxy7.runTest(Unknown Source) at com.example.ExampleTestCase.test(ExampleTestCase.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:244) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:814) Caused by: org.apache.axis2.AxisFault: org.apache.tuscany.sca.databinding.TransformationException: No matching source fault type is found at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:434) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:373) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:95) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:70) at
Re: How to create composite diagrams for the samples
Folks, What about the latest stuff in Eclipse STP project? Yours, Mike. Jean-Sebastien Delfino wrote: I'd like to understand how to create composite diagrams similar to the ones Simon already created for most samples. Do we have a quick summary of the steps to do this? Is there a set of predefined shapes uploaded somewhere that we all can use for these diagrams? Should I use a tool like inkscape to create the diagrams? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resetting state of service references at conversation end
Hi,
I checked in the code under r575101. Please look for o.a.t.sca.conversation
under the tuscany-core module.
I have to fix a few issues in the ConversationalTestCase to have the test
conform to the SCA java spec: CallableReference.getConversation() will
return null if no conversation is active.
It's a bit vague for ServiceReference.getConversationID(), the javadoc says:
getConversationID() - Returns the id supplied by the user that will be
associated with 925 conversations initiated through this reference.
But the spec also says:
496: If ServiceReference.getConversationID() is called after the
@EndsConversationmethod is called, but before the next conversation has been
started, it will return null.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, September 11, 2007 9:07 AM
Subject: Re: Resetting state of service references at conversation end
Raymond Feng wrote:
OK. I'll add the interfaces first for review. Should they go to the
core-spi?
Thanks,
Raymond
Only the interfaces actually used by binding and implementation extensions
should go to core-spi. If not needed by extensions they should go to core.
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service references at conversation end
I'm overall +1 with this proposal, with some minor changes described in
comments inline.
Raymond Feng wrote:
Hi,
As we agreed, the conversation id alone is not sufficient to deal with
conversations. We need to maintain the state of the conversations
(STARTED, ENDED or EXPIRED).
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it has ended.
I propose that we do the following:
1) Define a ConversationManager like:
public interface ConversationManager() {
String start(String conversationID); // If the conversationID is
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.
Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.
Also I think it's better to return the Conversation object (see below
for its contents).
void end(String conversationID); // Ends the conversation
void endConversation(Conversation conversation)
Don't you need another method to make a conversation expire?
ConversationState getConversationState(String conversationID); //
Get the state of the conversation
Conversation getConversation(Object conversationID)
void register(ConversationListener listener); // Register a listener
void unregister(ConversationListener listener); // Remove a listener
Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)
Also, these methods should be on the Conversation object described below
I think.
}
public interface ConversationListener() {
void conversationStarted(String conversationID);
void conversationEnded(String conversationID);
void conversationExpired(String conversationID);
}
Pass Conversation conversation instead of String conversationID.
If the methods are on the Conversation object instead of the
ConversationManager they can be simpler I think:
public interface ConversationListener() {
void conversationStarted();
void conversationEnded();
void conversationExpired();
}
public enum ConversationState {
STARTED, ENDED, EXPIRED
}
class Conversation {
ConversationState state;
Object conversationID;
}
Having this class allows you to evolve it over time, does not rely on
the fact that conversations are stored in a map, and also IMO better
represents what you'll store in persistent storage in the future.
Do we we need an expiry time field here as well?
2) The proxy or callable references will only keep the conversation ID.
Whenever the Conversation object is referenced or we need to perform
any actions to a conversation, we use the ID to look up the state of
the conversation.
3) Move the expiration timer from the ConversationScopeContainer to the
ConversationManager.
If different Conversations can have different expiration timers then the
timer needs to be on the Conversation object instead of the
ConversationManager.
4) The ConversationScopeContainer will be registered as listener to the
ConversationManager. When an active conversation is started, expired or
ended, the ConversationScopeContainer will be notified.
It might be easier to register the actual instance wrapper wrappering
the
Optimize the reference injection for java components
Hi, We use either JDK or CGLib proxies in reference injections for java components. It is a bit heavy and unnecessary for some cases. I now add a simple optimization to inject the implementation instance directly if the following criteria are met: 1) Both the source and target are java components 2) The binding is local SCA binding 3) The target implementation class implements/extends the source interface/class 4) The target component scope is either STATELESS or COMPOSITE 5) There is only one invoker (JavaImplementationInvoker) in each invocation chain for all the operations What do you think? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1690) Support SCA domain level autowire
[ https://issues.apache.org/jira/browse/TUSCANY-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1690: Fix Version/s: Java-SCA-Next Support SCA domain level autowire -- Key: TUSCANY-1690 URL: https://issues.apache.org/jira/browse/TUSCANY-1690 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-Next At this moment, we support autowire in the local composite. We need to add it for the domain-level too. -- 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-1639) I would suggent a improvement on WSDLInterfaceProcessor
[ https://issues.apache.org/jira/browse/TUSCANY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1639. - Resolution: Duplicate This JIRA duplicates JIRA TUSCANY-1646. I would suggent a improvement on WSDLInterfaceProcessor --- Key: TUSCANY-1639 URL: https://issues.apache.org/jira/browse/TUSCANY-1639 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: jdk1.5 eclipse windiows latest svn code Reporter: gengshaoguang Fix For: Java-SCA-Next Hi everyone, I would suggest the following: When reference a wsdl with referenceinterface.wsdl interface=[uri]//reference, the [uri] atttribute must be based on a preloaded local saved wsdl file. Would it be better if the developer specify a ?wsdl like uri, then the WSDLInterfaceProcessor could load it from remote/dynamic place instead of from classpath. If no one against my suggestion, I would like to do some thing more on this. -- 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-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
]
Jean-Sebastien Delfino updated TUSCANY-1656:
Priority: Minor (was: Major)
Changing priority to minor as a short term fix has been provided.
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] Updated: (TUSCANY-1356) Clean up binding-echo and implementation-crud samples
[ https://issues.apache.org/jira/browse/TUSCANY-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1356: Doing this will be an improvement but I don't think that it's a major issue, changing the priority to minor. Clean up binding-echo and implementation-crud samples - Key: TUSCANY-1356 URL: https://issues.apache.org/jira/browse/TUSCANY-1356 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: jira1356.diff, jira1356.svnst, jira1356.zip There is duplicate and confusing code in binding-echo and binding-echo-extension, and also in implementation-crud and implementation-crud-extension. See http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18926.html for more details of the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1162) Contribution Services - Enhance contribution repository
[ https://issues.apache.org/jira/browse/TUSCANY-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1162: Priority: Minor (was: Major) Contribution Services - Enhance contribution repository --- Key: TUSCANY-1162 URL: https://issues.apache.org/jira/browse/TUSCANY-1162 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-M2 Reporter: Luciano Resende Assignee: Luciano Resende Priority: Minor Fix For: Java-SCA-Next - Enhance and extend contribution repository - add contribute application (like launcher) - allow long lived contributions -- 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-545) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename.
[ https://issues.apache.org/jira/browse/TUSCANY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-545: --- Priority: Minor (was: Major) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. Key: TUSCANY-545 URL: https://issues.apache.org/jira/browse/TUSCANY-545 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Priority: Minor Fix For: Java-SCA-Next WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. -- 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-1398) Nested Callbacks Fail
[ https://issues.apache.org/jira/browse/TUSCANY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526989 ] Jean-Sebastien Delfino commented on TUSCANY-1398: - Could you please try your test case again? I think this is now fixed. Thanks. Nested Callbacks Fail - Key: TUSCANY-1398 URL: https://issues.apache.org/jira/browse/TUSCANY-1398 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.90, Java-SCA-Next Reporter: York (He Yuan) HUANG Fix For: Java-SCA-Next Attachments: non-block-orderprocess.zip I created a simple SCA application, which involves an order process. The application was attached. Below is the composite file of the application. Note that, the callback method of Supplier will invoke the callback interface of Customer. Thus, there are nested callbacks. ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://orderprocess; xmlns:cb=http://orderprocess; name=orderprocess component name=Customer implementation.java class=orderprocess.CustomerImpl/ reference name=supplier target=Supplier/Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /reference /component component name=Supplier service name=Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /service implementation.java class=orderprocess.SupplierImpl/ reference name=railway target=RailwayTransport/Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference reference name=highway target=HighwayTransport interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference /component component name=HighwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.HighwayTransport/ property name=period5000/property /component component name=RailwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.RaiwayTransport/ property name=period1000/property /component /composite However, the application fails on both SCA Java 0.90 and trunk. Below is the error message. When I debugged the application, I found that it might be caused by wrong from info in ThreadMessageContext. java.lang.NullPointerException at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:77) at $Proxy11.notify(Unknown Source) at orderprocess.SupplierImpl.notify(SupplierImpl.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:85) at $Proxy13.notify(Unknown Source) at orderprocess.RaiwayTransport.doShipping(RaiwayTransport.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at
[jira] Resolved: (TUSCANY-1398) Nested Callbacks Fail
[ https://issues.apache.org/jira/browse/TUSCANY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1398. - Resolution: Fixed Nested Callbacks Fail - Key: TUSCANY-1398 URL: https://issues.apache.org/jira/browse/TUSCANY-1398 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.90, Java-SCA-Next Reporter: York (He Yuan) HUANG Fix For: Java-SCA-Next Attachments: non-block-orderprocess.zip I created a simple SCA application, which involves an order process. The application was attached. Below is the composite file of the application. Note that, the callback method of Supplier will invoke the callback interface of Customer. Thus, there are nested callbacks. ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://orderprocess; xmlns:cb=http://orderprocess; name=orderprocess component name=Customer implementation.java class=orderprocess.CustomerImpl/ reference name=supplier target=Supplier/Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /reference /component component name=Supplier service name=Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /service implementation.java class=orderprocess.SupplierImpl/ reference name=railway target=RailwayTransport/Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference reference name=highway target=HighwayTransport interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference /component component name=HighwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.HighwayTransport/ property name=period5000/property /component component name=RailwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.RaiwayTransport/ property name=period1000/property /component /composite However, the application fails on both SCA Java 0.90 and trunk. Below is the error message. When I debugged the application, I found that it might be caused by wrong from info in ThreadMessageContext. java.lang.NullPointerException at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:77) at $Proxy11.notify(Unknown Source) at orderprocess.SupplierImpl.notify(SupplierImpl.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:85) at $Proxy13.notify(Unknown Source) at orderprocess.RaiwayTransport.doShipping(RaiwayTransport.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)RuntimeException invoking receiveResult:
Re: problem with resource initialization
hi Simon. Thanks for a good reply. I have been working on a few test-cases on tuscany for a while. I feel the instatiation of the domain should require parameters like the composite file in this case,taking up everything from the classpath would surely mess up things.Multiple components with the same name would not be able to exist in different composites as the Domain would always get into a deadloc which serivce or instance we are referring to. Other comments are welcome. Regards Mayank Sharma
use of datasource
hi, How can we use datasources in SCA? I mean how can we create and initialise data-sources in SCA and use them. Regards Mayank Sharma
Re: use of datasource
Right now, you can either consider the data-source an implementation detail of your component, and initialize it as you would in a regular application, or you could use other aproaches, like what we have in implementation.das and implementation.data, where you can define it together with your component definition : component name=DASServiceComponent tuscany:implementation.das config=/CompanyConfig.xml dataAccessType=rdb tuscany:connectionInfo dataSource=java:comp/env/jdbc/dastest/ /tuscany:implementation.das /component In this case, DAS will take care of initializing the data-sources and you could use DAS to access your RDB data. Please let me know if you have more questions. On 9/12/07, mayank sharma [EMAIL PROTECTED] wrote: hi, How can we use datasources in SCA? I mean how can we create and initialise data-sources in SCA and use them. Regards Mayank Sharma -- 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]
