[jira] Created: (TUSCANY-1929) when query does not include only pk , java.lang.RuntimeException is returned
when query does not include only pk , java.lang.RuntimeException is returned Key: TUSCANY-1929 URL: https://issues.apache.org/jira/browse/TUSCANY-1929 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 2, access mdb - no access installed, sca 1.0 Reporter: Kristina hi all, not sure if this is a bug or is just me... bottom line i need help :) i am trying to use das to read data from an access mdb into an dataobject (sdo) DAS das = DAS.FACTORY.createDAS(con); String sql = select * from [ + tablename+ ] ; Command readTableData = das.createCommand(sql); DataObject root = readTableData.executeQuery(); when trying to run the code above, i get Table WD Peripheral HD Controller in query does not include Primary Key column or has null value in it, can not proceed! same error if i set the pk using ConfigHelper.addprimarykey(pk) same error if the sql string contains all fields from the table, pk included error message ** java.lang.RuntimeException: Table WD Peripheral HD Controller in query does not include Primary Key column or has null value in it, can not proceed! at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.addRowToGraph(ResultSetProcessor.java:117) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResultSet(ResultSetProcessor.java:91) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResults(ResultSetProcessor.java:77) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.buildGraph(ReadCommandImpl.java:309) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(ReadCommandImpl.java:277) *** end error message *** if the sql string looks like this: String sql = select + pk + from [ + tablename+ ] ; i get no error message but when trying to generate the xml from dataobject root, i get an empty one. String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); what am i doing wrong? thanks, kristina -- 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]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=26540projectId=277 Build statistics: State: Error Previous State: Error Started at: Wed 5 Dec 2007 01:07:11 -0800 Finished at: Wed 5 Dec 2007 01:07:20 -0800 Total time: 9s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Type 'svn help' for usage. --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1929) generate xml from dataobject
[ https://issues.apache.org/jira/browse/TUSCANY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristina updated TUSCANY-1929: --- Description: hi all, not sure if this is a bug or is just me... bottom line i need help :) when trying to generate the xml from dataobject , i get an empty one eventhough the dataobject is filled I am using: String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); where root is my dataobject what am i doing wrong? thanks, kristina was: hi all, not sure if this is a bug or is just me... bottom line i need help :) i am trying to use das to read data from an access mdb into an dataobject (sdo) DAS das = DAS.FACTORY.createDAS(con); String sql = select * from [ + tablename+ ] ; Command readTableData = das.createCommand(sql); DataObject root = readTableData.executeQuery(); when trying to run the code above, i get Table WD Peripheral HD Controller in query does not include Primary Key column or has null value in it, can not proceed! same error if i set the pk using ConfigHelper.addprimarykey(pk) same error if the sql string contains all fields from the table, pk included error message ** java.lang.RuntimeException: Table WD Peripheral HD Controller in query does not include Primary Key column or has null value in it, can not proceed! at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.addRowToGraph(ResultSetProcessor.java:117) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResultSet(ResultSetProcessor.java:91) at org.apache.tuscany.das.rdb.graphbuilder.impl.ResultSetProcessor.processResults(ResultSetProcessor.java:77) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.buildGraph(ReadCommandImpl.java:309) at org.apache.tuscany.das.rdb.impl.ReadCommandImpl.executeQuery(ReadCommandImpl.java:277) *** end error message *** if the sql string looks like this: String sql = select + pk + from [ + tablename+ ] ; i get no error message but when trying to generate the xml from dataobject root, i get an empty one. String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); what am i doing wrong? thanks, kristina Summary: generate xml from dataobject (was: when query does not include only pk , java.lang.RuntimeException is returned) generate xml from dataobject Key: TUSCANY-1929 URL: https://issues.apache.org/jira/browse/TUSCANY-1929 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 2, access mdb - no access installed, sca 1.0 Reporter: Kristina hi all, not sure if this is a bug or is just me... bottom line i need help :) when trying to generate the xml from dataobject , i get an empty one eventhough the dataobject is filled I am using: String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); where root is my dataobject what am i doing wrong? thanks, kristina -- 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: Distributed online store scenario, was: Updated online store tutorial
On Dec 5, 2007 8:29 AM, Simon Laws [EMAIL PROTECTED] wrote: Hi An update of where I'm up to... Simon On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: To get me going on this I've experimented with moving the FruitsCatalog out of the cloud and into a webapp. The web app relies on the evolving deep tomcat integration so starting the scenario requires the following steps Unzip the distribution/tomcat zip over your tomcat installation Set the tomcat/sca-contributions/tuscany.properties file to include node and domain URLs that are to your liking. Copy tutorial-catalog-jse.war to tomcat/webapps Run LaunchCloud Run LaunchStoreDistributed And you are set. Thanks a lot, I'll update and will try it. It's all a bit fragile at the moment so lots of things to do, for example, the domain is a pain as it doesn't track when things go away so it can get confusing. However lets try and get the majority of the scenario working and we can then look back and see where the holes are. I haven't done anything with the EJB code you made yet other than look at it. I could start building the EJB for the vegetable catalog if you like. Yes, here are the steps I was thinking about: 1. develop the EJB code 2. deploy it to Geronimo 3. come up with a version of store.composite with the vegetablesCatalog reference configured with the proper EJB binding 4. figure what the business interface for that reference looks like (I'm hoping that this will help shed some light on the POJO and databindings discussion) 5. get that working end to end I've done 1-5 but with very little thought about 4 other than take the VegetablesCatalog interface as it. There is a catalog-ejb project now under tutorial. This deploys to Geronimo and I've updated the distributed store to use a specifically configured binding. I had to change the domain to 9998 as Geronimo uses so some of the other bits of the tutorial may not work at the moment. and in a second step: 6. add a description of the EJB app to the domain 7. on the vegetablesCatalog reference, replace the binding.ejb uri=.../ by a wire with target=VegetableCatalog 8. get that working end to end I'm assuming from what you say that we will deploy the EJB app to Geronimo standalone as if it had existed before we came along with SCA. Yes Where will the composite that references this EJB be deployed to? I'm struggling with how to satisfy The idea is to be able to develop the scenario and explore how to work with existing JEE apps and different containers in an SCA domain without piling more runtime code into Tuscany. as it seems that we will need to deploy the composite that references the EJB to Geronimo which, in turn, means bringing up the Geronimo/Tuscany integration code again. I think that adding a composite to the domain does not necessarily imply download that composite to the Tuscany-enabled container that runs the components it describes. In other words I'm hoping that we can add to the domain a composite that describes an application without having to install the Tuscany Java runtime to the container that runs it. That's one of the reasons why I brought up that scenario: To help us explore what a domain really is and the idea that an SCA domain is more than a bunch of Tuscany-Java runtimes that use a Tuscany-specific protocol to advertise/discover their services. I have been working on bringing the Geronimo plugin back up again with the code in trunk and that is almost done now so we have some options about how we want to ply this. We could add the ability to introduce service descriptions to the domain regardless of whether the service is running on a Tuscany enabled endpoint although I haven't done this yet. We need to agree how this would be achieved from the users point of view. For example, is this a specific interface for associating the domain with existing services or is it to use the existing contribution interfaces with composites marked in some way that indicates that they are not to be deployed for real but simply added to the domain. Generally we need the ability on the domain to view and manipulate component definitions so that the deployment process is more flexible for situations when the domain level composite is modified. The deployment of virtual components could be part of this. I'll have a play this morning and see if any inspiration comes. I have spent time bringing up the Geronimo plugin to work with the code in trunk so we can play with a number of different scenarios. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1932) Conversion between SDO String and Strings type is not working
Conversion between SDO String and Strings type is not working - Key: TUSCANY-1932 URL: https://issues.apache.org/jira/browse/TUSCANY-1932 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Attachments: XMLSimpleTypeTest.java, XMLTypes.xsd According to SDO spec, DataObject.getString() and setString() on SDO Strings type (xsd:NMTOKENS) property (implemented by java.util.List) should automatically convert between java.lang.String and java.util.List. For example, invoking DataObject.getString() on xsd:NMTOKENS property with list value of [token1, token2, token3] should return the string value as token1 token2 token3 delimited by space. String value = dataObject.getString(stringsProperty); // Should return token1 token2 token3 Similarly, invoking DataObject.setString() on xsd:NMTOKENS property with string value like token1 token2 token3 should set the property value to the list of [token1, token2, token3]. dataObject.setString(stringsProperty, token1 token2 token3) // stringsProperty's value should be a list with value of [token1, token2, token3] -- 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]
Wendy Hsu is out of the office for vacation
I will be out of the office starting 12/05/2007 and will not return until 12/31/2007. I will respond to your message when I return.
[jira] Updated: (TUSCANY-1932) Conversion between SDO String and Strings type is not working
[ https://issues.apache.org/jira/browse/TUSCANY-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1932: Attachment: XMLSimpleTypeTest.java XMLTypes.xsd Conversion between SDO String and Strings type is not working - Key: TUSCANY-1932 URL: https://issues.apache.org/jira/browse/TUSCANY-1932 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Attachments: XMLSimpleTypeTest.java, XMLTypes.xsd According to SDO spec, DataObject.getString() and setString() on SDO Strings type (xsd:NMTOKENS) property (implemented by java.util.List) should automatically convert between java.lang.String and java.util.List. For example, invoking DataObject.getString() on xsd:NMTOKENS property with list value of [token1, token2, token3] should return the string value as token1 token2 token3 delimited by space. String value = dataObject.getString(stringsProperty); // Should return token1 token2 token3 Similarly, invoking DataObject.setString() on xsd:NMTOKENS property with string value like token1 token2 token3 should set the property value to the list of [token1, token2, token3]. dataObject.setString(stringsProperty, token1 token2 token3) // stringsProperty's value should be a list with value of [token1, token2, token3] -- 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-1929) generate xml from dataobject
[ https://issues.apache.org/jira/browse/TUSCANY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1929: Attachment: XMLHelperSample.java Here is a sample of the XMLHelper generating an instance XML. generate xml from dataobject Key: TUSCANY-1929 URL: https://issues.apache.org/jira/browse/TUSCANY-1929 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 2, access mdb - no access installed, sca 1.0 Reporter: Kristina Attachments: XMLHelperSample.java hi all, not sure if this is a bug or is just me... bottom line i need help :) when trying to generate the xml from dataobject , i get an empty one eventhough the dataobject is filled I am using: String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); where root is my dataobject what am i doing wrong? thanks, kristina -- 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: Remotable interfaces and pass by value, was: Data transformation from/to POJO
Hi, What we have today is mostly in line with your proposal. Only a few twicks are needed. 1) If the data type is recognized by a known databinding, for example, SDO or JAXB, the databinding specific-copy is used. For SDO, it will be SDO CopyHelper.copy and for JAXB, it will be marshal/unmarshal. (This is the what we do in the code). 2) If the object implements java.io.Serializable, it is copied using Java serialization [2] (We already have it) 3) Assuming we have a simple JavaBean, and it is copied using JAXB XML serialization [3] (To be added) Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, December 04, 2007 3:26 PM Subject: Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO Jean-Sebastien Delfino wrote: Some answers after researching the spec docs: Raymond Feng wrote: Hi, I think this issue needs to be brought up at the spec level. Basically, the following have to be clarified: 1) What interfaces are qualified to be remotable? 2) What are the characteristics of the input/output types for remotable interfaces? Assembly spec: 697 Whether a service of a component implementation is remotable is defined by the interface of the service. In the case of Java this is defined by adding the @Remotable annotation to the Java interface (see Client and Implementation Model Specification for Java). WSDL defined interfaces are always remotable. Java SCA Annotations and APIs spec: 297 Java interfaces generated from a WSDL portType are always remotable. I think that says that JAX-WS generated interfaces should be considered remotable even in the absence of an @Remotable interface. Java SCA Annotations and APIs spec: 1531 Complex data types exchanged via remotable service interfaces must be compatible with the marshalling technology used by the service binding. For example, if the service is going to be exposed using the standard web service binding, then the parameters must be Service Data Objects (SDOs) 2.0 [2] or JAXB [3] types. Independent of whether the remotable service is called from outside of the composite that contains it or from another component in the same composite, the data exchange semantics are by-value. This leaves the door open for other data representations supported by other service bindings, e.g. a DOM or a Java Serializable object. The Java SCA Annotations and APIs spec Errata adds this: The SCA Client and Implementation Model for Java applies the WSDL to Java and Java to WSDL mapping rules as defined by the JAX-WS specification [4] for generating remotable Java interfaces from WSDL portTypes and vice versa. For the purposes of the Java-to-WSDL mapping algorithm, the interface is treated as if it had a @WebService annotation on the class, even if it doesn't, and the org.osoa.OneWay annotation should be treated as a synonym for javax.jws.OneWay. For the WSDL-to-Java, the generated @WebService annotation should imply that the interface is @Remotable. For the mapping from Java types to XML schema types SCA supports both the SDO 2.1 [2] mapping and the JAXB [3] mapping. Having a choice of binding technologies is allowed, as noted in the first paragraph of section 5 of the JSR 181 (version 2) specification, which is referenced by the JAX-WS specification. EJB binding spec: 105 When used with the EJB binding, a service or reference interface must be compatible with a session bean interface, according to the following rules: - The interface offered by a reference MUST be remotable if the remote session bean interface is being accessed, and MUST be local if the local session bean interface is being accessed. - The methods on the session bean MUST be a compatible superset of the methods in the interface used by the reference. - The interface used by a reference MAY NOT contain any methods inherited from EJBObject or EJBLocalObject. - Compatibility for an individual method is defined by the SCA Assembly Model Specification [4], and can be stated simply as compatibility of the signature. That is, the method name, input types, and output types MUST be identical. - The order of the input and output types also MUST be identical. This brings interesting points: - EJB binding does not imply remote, local interfaces are also supported (contrary to the common belief that binding implies remote). - an SCA reference can use a newly defined Java interface (compatible with the session bean interface but not dragging javax.ejb.Remote) with a @Remotable annotation. 3) What are the semantics of pass-by-value? Assembly spec: 706 Independent of whether the remotable service is called remotely from outside the process where the service runs or from another component running in the same process, the data exchange semantics are by-value. Implementations of remotable services may modify input messages (parameters) during
[jira] Commented: (TUSCANY-1929) generate xml from dataobject
[ https://issues.apache.org/jira/browse/TUSCANY-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548803 ] David T. Adcox commented on TUSCANY-1929: - Kristina, One thing that is not clear is whether or not you are getting 'anything' returned in the 'generatedXml' variable. I would expect to see some contents. If you are getting something from the call, could you attach what you are seeing, to this JIRA? I will post a simple sample of the XMLHelper class doing what you are attempting to do in the code above. My sample will generate a type, create an instance of that type, then display the contents of the instance in both XML and from the data object directly. The DO dump is a very abbreviated version of what you can find demonstrated in the org.apache.tuscany.samples.sdo.advanced.PrintDataGraph sample found in sample-sdo porject. generate xml from dataobject Key: TUSCANY-1929 URL: https://issues.apache.org/jira/browse/TUSCANY-1929 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: java ee 1.5, eclipse 3.3.1.1. , windows xp, das 1.0 beta 2, access mdb - no access installed, sca 1.0 Reporter: Kristina hi all, not sure if this is a bug or is just me... bottom line i need help :) when trying to generate the xml from dataobject , i get an empty one eventhough the dataobject is filled I am using: String generatedXml = XMLHelper.INSTANCE.save(root, http://helloworld2;, MaterialListForTest); where root is my dataobject what am i doing wrong? thanks, kristina -- 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: Data transformation from/to POJO
Hi,
I have checked in the first cut under
http://svn.apache.org/viewvc?rev=601501view=rev. With these changes, we now
use JAXB databinding to deal with POJOs (including simple and complex
types). By the JAXB Java to XML default mapping, POJOs are supported in line
with the JavaBeans patterns with the flowing rules.
1) There is a protected or public no-arg constructor
2) A property is either a public field or public setter getter. Even for
Collection type, the setter is required.
3) The property can not be an interface
4) Circular object reference is not supported
5) References to the same object are flattened
One caveat is that it brings the jaxb-api and jaxb-impl as core dependencies
(about 1MB). We could try to implement the default Java/XML mapping by
ourselves if that's desirable.
There are also other things we need to improve, for example, how to render a
JAXB object as XMLStreamReader. The quick and dirty way is to marshal the
JAXB object into a byte array and create XMLStreamReader out of it. We could
even use the fast-infoset to help the performance of the round trip.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, November 27, 2007 1:18 PM
Subject: Re: Data transformation from/to POJO
Raymond Feng wrote:
I think there are two options:
1) Make the JAXB databinding as the default databinding for POJOs (simple
and complex types).
What about doing that? any drawback?
2) Keep the POJO databindings and implement the POJO--XML transformers
using JAXB-impl
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, November 26, 2007 3:26 PM
Subject: Re: Data transformation from/to POJO
Raymond Feng wrote:
Hi,
I just did a test to see how JAXB-RI handles the POJO without any
annotations. The result seems to be promising.
I started with a POJO:
public class MyBean {
private int age;
private String name;
private ListString notes = new ArrayListString();
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public ListString getNotes() {
return notes;
}
public void setNotes(ListString notes) {
this.notes = notes;
}
}
The following test case is then successful.
public void testPOJO() throws Exception {
JAXBContext context = JAXBContext.newInstance(MyBean.class);
StringWriter writer = new StringWriter();
MyBean bean = new MyBean();
bean.setName(Test);
bean.setAge(20);
bean.getNotes().add(1);
bean.getNotes().add(2);
JAXBElementObject element = new JAXBElementObject(new
QName(http://ns1;, bean), Object.class, bean);
context.createMarshaller().marshal(element, writer);
System.out.println(writer.toString());
Object result = context.createUnmarshaller().unmarshal(new
StringReader(writer.toString()));
assertTrue(result instanceof JAXBElement);
JAXBElement e2 = (JAXBElement)result;
assertTrue(e2.getValue() instanceof MyBean);
}
?xml version=1.0 encoding=UTF-8 standalone=yes?ns2:bean
xsi:type=myBean xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:ns2=http://ns1;age20/agenameTest/name/ns2:bean
Good that it seems promising :) what do I need to do to get the JaxB to
XML transformer to pick up the Item bean in the store tutorial?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation Policies
Would it help if the Intent/PolicySet has a pointer to the its attachpoint (i.e., where the intent/policy is declared)? Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, December 05, 2007 1:40 AM Subject: Implementation Policies Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded. - * So if we are going to store in the component model, the policysets specified on its implementation then during validation its not possible to figure out if the policyset came thro inheriting the component's policyset or from direct definition. Is there a way out of this ? Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany SCA build failing - requires a svn clean up on the continuum build machine
Could someone with access to the VMBuild machine do a svn cleanup to try to recover from the build error below. I tried to change the settings on the continuum environment to start from a fresh checkout, but I'm not sure that would solve the problem. -- Forwarded message -- From: Continuum VMBuild Server [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Date: Tue, 04 Dec 07 16:58:24 -0800 Subject: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=26292projectId=277 Build statistics: State: Error Previous State: Error Started at: Tue 4 Dec 2007 16:54:31 -0800 Finished at: Tue 4 Dec 2007 16:56:09 -0800 Total time: 1m 37s Build Trigger: Schedule Build Number: 0 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Error: Provider message: The svn command failed. Command output: --- svn: Working copy '.' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) Type 'svn help' for usage. --- -- 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]
Implementation Policies
Hi, To set the context its about specification of policies on implementation elements in a composite. Since we have implementation model instances being reused we have trouble with capturing what policies were set on an implementation under a specific Component. I have this going in the trunk but with a bit of a hack in ComponentImpl.getImplementation. Now am looking at cleaning that a bit and exploring options. One of the alternatives suggested earlier is to have the implementation policies stored in the component itself. But the problem is Component themselves can have policies specified over them which will have be inherited by the service, implementation and reference child elements within. One way of getting around this is to add up the component's policies to the services and references child elements right at the time of reading from the scdl. Then when the implementation child element is loaded we read its policies and store it into the component. This seems a good way out but bites during the build phase as follows :- - One of the things we do in the build phase is validating if policysets specified on an implementation element i.e. checking to see if a specified policyset does apply to the implementation type in question. The specs says that its ok if this validation fails for policysets that have been inherited (say from the composite or the component), but if this validation fails for a policyset directly specified for the element then its an error in defining the composite and it must be flagged. * 551 When computing the policySets that apply to a particular element, the @appliesTo attribute 552 of each relevant policySet is checked against the element. If the policySet is attached 553 directly to the element and does not apply to that element an error is raised. If a policySet 554 that is attached to an ancestor element does not apply to the element in question, it is simply 555 discarded. - * So if we are going to store in the component model, the policysets specified on its implementation then during validation its not possible to figure out if the policyset came thro inheriting the component's policyset or from direct definition. Is there a way out of this ? Thanks. - Venkat
Re: [jira] Problems calling the real stock quote
Hi,
It seems that the component business logic ran into a RemoteException and the
Tuscany runtime doesn't know how to map it to a fault for the Web Service. The
bad news is that we don't dump the orginal exception in this case. The error
handling could be improved.
I suggest you look into the component implementation code to figure out what's
behind the exception.
Thanks,
Raymond
- Original Message -
From: Mahi
To: tuscany-dev@ws.apache.org
Sent: Monday, December 03, 2007 1:58 PM
Subject: [jira] Problems calling the real stock quote
Driver: apache-tuscany-sca-1.0.1-incubating-src
I am trying to invoke the live stock service that was used in older (m1 ans
m2) drivers. I have attached the WSDL file. I have tested this web service in
Web Services Explorer in RAD, and it works.
I am pasting code followed by the exception when I run it.
Stockquote.composite
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:wsdli=http://www.w3.org/2006/01/wsdl-instance;
name=StockQuoteWS
component name=StockQuoteServiceComponent
implementation.java class=stockquote.StockQuoteServiceImpl/
/component
reference name=StockQuoteService
promote=StockQuoteServiceComponent/stockQuoteService
interface.wsdl
interface=http://www.webserviceX.NET/#wsdl.interface(StockQuoteSoap)
wsdli:wsdlLocation=http://www.webserviceX.NET/
wsdl/stockquote.wsdl /
binding.ws
endpoint=http://www.webserviceX.NET/#wsdl.endpoint(StockQuote/StockQuoteSoap)
location=wsdl/stockquote.wsdl /
/reference
/composite
StockQuoteServiceImpl.java:
public class StockQuoteServiceImpl implements StockQuoteService {
StockQuoteSoap stockQuoteService = null; // Injected by the SCA container.
@Constructor
public StockQuoteServiceImpl(@Reference(name = stockQuoteService,
required = true)
StockQuoteSoap stockQuoteService) {
this.stockQuoteService = stockQuoteService;
}
/**
* @throws RemoteException
*/
public Map getQuotes(final String[] symbols) throws RemoteException {
try {
if (stockQuoteService == null)
System.out.println(stockQuoteService was not set by the SCA
runtime!);
StockClient.java that I am using to test:
public class StockClient {
public static void main(String[] args) throws Exception {
SCADomain scaDomain = SCADomain.newInstance(stockquote.composite);
StockQuoteService stockQuoteService =
scaDomain.getService(StockQuoteService.class,
StockQuoteServiceComponent);
String[] stocks = {IBM};
System.out.println(stockQuoteService.getQuotes(stocks));
scaDomain.close();
}
}
The following is the exception I am getting running the client:
org.apache.tuscany.sca.databinding.TransformationException: Target fault type
cannot be resolved: class java.rmi.RemoteException
org.apache.axiom.om.OMElement Element: {http://stockquote/}RemoteException
Type: null
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:126)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:233)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:130)
at $Proxy6.getQuote(Unknown Source)
at
stockquote.StockQuoteServiceImpl.getQuotes(StockQuoteServiceImpl.java:64)
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.PassByValueInterceptor.invoke(PassByValueInterceptor.java:49)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:233)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:130)
at $Proxy5.getQuotes(Unknown Source)
at test.StockClient.main(StockClient.java:20)
Exception in thread main java.rmi.RemoteException:
org.apache.tuscany.sca.databinding.TransformationExceptionTarget fault type
cannot be resolved: class java.rmi.RemoteException
org.apache.axiom.om.OMElement Element: {http://stockquote/}RemoteException
Type: null; nested exception is:
Re: Remotable interfaces and pass by value, was: Data transformation from/to POJO
2007/12/5, Jean-Sebastien Delfino [EMAIL PROTECTED]: Jean-Sebastien Delfino wrote: Some answers after researching the spec docs: Raymond Feng wrote: Hi, I think this issue needs to be brought up at the spec level. Basically, the following have to be clarified: 1) What interfaces are qualified to be remotable? 2) What are the characteristics of the input/output types for remotable interfaces? Assembly spec: 697 Whether a service of a component implementation is remotable is defined by the interface of the service. In the case of Java this is defined by adding the @Remotable annotation to the Java interface (see Client and Implementation Model Specification for Java). WSDL defined interfaces are always remotable. Java SCA Annotations and APIs spec: 297 Java interfaces generated from a WSDL portType are always remotable. I think that says that JAX-WS generated interfaces should be considered remotable even in the absence of an @Remotable interface. Java SCA Annotations and APIs spec: 1531 Complex data types exchanged via remotable service interfaces must be compatible with the marshalling technology used by the service binding. For example, if the service is going to be exposed using the standard web service binding, then the parameters must be Service Data Objects (SDOs) 2.0 [2] or JAXB [3] types. Independent of whether the remotable service is called from outside of the composite that contains it or from another component in the same composite, the data exchange semantics are by-value. This leaves the door open for other data representations supported by other service bindings, e.g. a DOM or a Java Serializable object. The Java SCA Annotations and APIs spec Errata adds this: The SCA Client and Implementation Model for Java applies the WSDL to Java and Java to WSDL mapping rules as defined by the JAX-WS specification [4] for generating remotable Java interfaces from WSDL portTypes and vice versa. For the purposes of the Java-to-WSDL mapping algorithm, the interface is treated as if it had a @WebService annotation on the class, even if it doesn't, and the org.osoa.OneWay annotation should be treated as a synonym for javax.jws.OneWay. For the WSDL-to-Java, the generated @WebService annotation should imply that the interface is @Remotable. For the mapping from Java types to XML schema types SCA supports both the SDO 2.1 [2] mapping and the JAXB [3] mapping. Having a choice of binding technologies is allowed, as noted in the first paragraph of section 5 of the JSR 181 (version 2) specification, which is referenced by the JAX-WS specification. EJB binding spec: 105 When used with the EJB binding, a service or reference interface must be compatible with a session bean interface, according to the following rules: - The interface offered by a reference MUST be remotable if the remote session bean interface is being accessed, and MUST be local if the local session bean interface is being accessed. - The methods on the session bean MUST be a compatible superset of the methods in the interface used by the reference. - The interface used by a reference MAY NOT contain any methods inherited from EJBObject or EJBLocalObject. - Compatibility for an individual method is defined by the SCA Assembly Model Specification [4], and can be stated simply as compatibility of the signature. That is, the method name, input types, and output types MUST be identical. - The order of the input and output types also MUST be identical. This brings interesting points: - EJB binding does not imply remote, local interfaces are also supported (contrary to the common belief that binding implies remote). - an SCA reference can use a newly defined Java interface (compatible with the session bean interface but not dragging javax.ejb.Remote) with a @Remotable annotation. 3) What are the semantics of pass-by-value? Assembly spec: 706 Independent of whether the remotable service is called remotely from outside the process where the service runs or from another component running in the same process, the data exchange semantics are by-value. Implementations of remotable services may modify input messages (parameters) during or after an invocation and may modify return messages (results) after the invocation. If a remotable service is called locally or remotely, the SCA container is responsible for making sure that no modification of input messages or post-invocation modifications to return messages are seen by the caller. Does that help answer your questions? So, based on all the above, I'd like to come up with a reasonable implementation of the pass-by-value behavior for in-VM interactions. By in-VM I mean: - a reference is wired to a service - both run in the same node - the SCA binding is used. Disclaimer: In-VM can have many different meanings so people
[jira] Created: (TUSCANY-1930) Wire specified in composite file not working
Wire specified in composite file not working
Key: TUSCANY-1930
URL: https://issues.apache.org/jira/browse/TUSCANY-1930
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1, Java-SCA-1.1
Environment: jre1.5.0_11 and jre1.6.0_03
Reporter: Andy Verberne
When using a wire in my own composite file I got the error message and stack
trace as specified further down.
After debugging the source code of the SCA Assembly Model component I found
that this error can easily be reproduced by modifying the existing integration
test:
org.apache.tuscany.sca.itest.WireTestCase.java
This integration test does run successful but will fail when one makes the
following changes in the accompanying WireTest.composite file:
Chnage:
component name=WireService
implementation.java
class=org.apache.tuscany.sca.itest.WireServiceImpl/
/component
wire source=WireClient/aWireService target=WireService/WireService/
into:
component name=WireServiceComponent
implementation.java
class=org.apache.tuscany.sca.itest.WireServiceImpl/
/component
wire source=WireClient/aWireService
target=WireServiceComponent/WireService/
Notice the change of the component name. The bug in the code is such that the
wire will only work when the component and service name, specified in the
target of the wire (i.e. target=WireService/WireService) are equal. As is the
case in the current integration test. When the component name and service name
are different the wire will fail.
I was able to fix the bug by modifying one line in the file:
org.apache.tuscany.sca.assembly.builder.impl.CompositeWireBuilderImpl.java
I have attached this as a patch.
I will also create a new issue in Jira proposing to modify the integration test
in order to detect this bug.
However, I am not entirely sure whether this fix doesn't break other things.
The code preceding the line of of code I modified is rather suspicious:
// Resolve the target service
ComponentService target = wire.getTarget();
if (target != null target.isUnresolved()) {
resolvedService = componentServices.get(target.getName());
if (resolvedService != null) {
wire.setTarget(target);
The last line doesn't really do anything useful. So maybe this code needs
refactoring ...
Error message:
5-dec-2007 14:03:33
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Component reference target not found, it might be a remote service:
WireService
Stack trace:
org.osoa.sca.ServiceUnavailableException: No service invoker is available for
reference aWireService (bindingURI=null operation=sayHello).
at
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:192)
at
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:214)
at
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:156)
at
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:190)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:124)
at $Proxy7.sayHello(Unknown Source)
at
org.apache.tuscany.sca.itest.WireClientImpl.runTests(WireClientImpl.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:105)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:49)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:233)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:130)
at $Proxy6.runTests(Unknown Source)
at
org.apache.tuscany.sca.itest.WireTestCase.testWire(WireTestCase.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at
Unexpected/Unknown option argument when linking rest interface
I'm trying to build the SCA's REST extension, but I'm getting a strange error in every attempt to link...it shows: [exec] mt.exe : command line error c1010007: Unexpected/Unknown option Release\cpp\sca\runtime\core\src\.libs/tuscany_sca.dll;2. Use the /? option for help on usage and samples. Bellow the complete ant output: E:\Adriano\Faculdade\Tuscany\Native Release\cpp\scaant Buildfile: build.xml all: build.core: build: compile: compile.core: [cc] Starting dependency analysis for 5 files. [cc] 5 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. compile.extension: [cc] Starting dependency analysis for 4 files. [cc] 4 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. compile.model: [cc] Starting dependency analysis for 21 files. [cc] 21 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. compile.util: [cc] Starting dependency analysis for 12 files. [cc] 12 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. link: [cc] 0 total files to be compiled. [exec] Microsoft (R) Manifest Tool version 5.2.3790.2014 [exec] Copyright (c) Microsoft Corporation 2005. [exec] All rights reserved. [exec] [exec] mt.exe : command line error c1010007: Unexpected/Unknown option Release\cpp\sca\runtime\core\src\.libs/tuscany_sca.dll;2. Use the /? option for help on usage and samples. install.core: install: install.core: [copy] Copying 5 files to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\include\tuscany\sca\core install.extension: [copy] Copying 4 files to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\include\tuscany\sca\extension install.model: [copy] Copying 21 files to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\include\tuscany\sca\model install.util: [copy] Copying 13 files to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\include\tuscany\sca\util install.xsd: [copy] Copying 12 files to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\xsd [copy] Copying 1 file to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\include\tuscany\sca [copy] Copying 1 file to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\lib [copy] Copying 1 file to E:\Adriano\Faculdade\Tuscany\Native Release\cpp\sca\deploy\bin build.extensions: build: build.extension.cpp: build: compile: compile.cpp.osoa: [cc] Starting dependency analysis for 2 files. [cc] 2 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. compile.cpp.core: [cc] Starting dependency analysis for 8 files. [cc] 8 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. compile.cpp.model: [cc] Starting dependency analysis for 4 files. [cc] 4 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. init: scagen.jar: link: [cc] 0 total files to be compiled. [cc] Starting link [cc]Creating library tuscany_sca_cpp.lib and object tuscany_sca_cpp.exp [exec] Microsoft (R) Manifest Tool version 5.2.3790.2014 [exec] Copyright (c) Microsoft Corporation 2005. [exec] All rights reserved. [exec] [exec] mt.exe : command line error c1010007: Unexpected/Unknown option Release\cpp\sca\runtime\extensions\cpp\src\.libs/tuscany_sca_cpp.dll;2. Use the /? option for help on usage and samples. build.extension.php: build: compile: check.php: [echo] TuscanySCA php extension is not enabled compile.php.core: check.php: [echo] TuscanySCA php extension is not enabled compile.php.model: check.php: [echo] TuscanySCA php extension is not enabled link: build.extension.python: build: compile: check.python: [echo] TuscanySCA python extension is not enabled compile.python.core: check.python: [echo] TuscanySCA python extension is not enabled compile.python.model: check.python: [echo] TuscanySCA python extension is not enabled link: build.extension.rest: build: compile: check.rest: compile.rest.interface.core: [cc] Starting dependency analysis for 1 files. [cc] 1 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled. check.rest: compile.rest.interface.model: [cc] Starting dependency analysis for 1 files. [cc] 1 files are up to date. [cc] 0 files to be recompiled from dependency analysis. [cc] 0 total files to be compiled.
Re: Distributed online store scenario, was: Updated online store tutorial
Hi An update of where I'm up to... Simon On Dec 4, 2007 9:53 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Simon Laws wrote: To get me going on this I've experimented with moving the FruitsCatalog out of the cloud and into a webapp. The web app relies on the evolving deep tomcat integration so starting the scenario requires the following steps Unzip the distribution/tomcat zip over your tomcat installation Set the tomcat/sca-contributions/tuscany.properties file to include node and domain URLs that are to your liking. Copy tutorial-catalog-jse.war to tomcat/webapps Run LaunchCloud Run LaunchStoreDistributed And you are set. Thanks a lot, I'll update and will try it. It's all a bit fragile at the moment so lots of things to do, for example, the domain is a pain as it doesn't track when things go away so it can get confusing. However lets try and get the majority of the scenario working and we can then look back and see where the holes are. I haven't done anything with the EJB code you made yet other than look at it. I could start building the EJB for the vegetable catalog if you like. Yes, here are the steps I was thinking about: 1. develop the EJB code 2. deploy it to Geronimo 3. come up with a version of store.composite with the vegetablesCatalog reference configured with the proper EJB binding 4. figure what the business interface for that reference looks like (I'm hoping that this will help shed some light on the POJO and databindings discussion) 5. get that working end to end I've done 1-5 but with very little thought about 4 other than take the VegetablesCatalog interface as it. There is a catalog-ejb project now under tutorial. This deploys to Geronimo and I've updated the distributed store to use a specifically configured binding. I had to change the domain to 9998 as Geronimo uses so some of the other bits of the tutorial may not work at the moment. and in a second step: 6. add a description of the EJB app to the domain 7. on the vegetablesCatalog reference, replace the binding.ejb uri=.../ by a wire with target=VegetableCatalog 8. get that working end to end I'm assuming from what you say that we will deploy the EJB app to Geronimo standalone as if it had existed before we came along with SCA. Yes Where will the composite that references this EJB be deployed to? I'm struggling with how to satisfy The idea is to be able to develop the scenario and explore how to work with existing JEE apps and different containers in an SCA domain without piling more runtime code into Tuscany. as it seems that we will need to deploy the composite that references the EJB to Geronimo which, in turn, means bringing up the Geronimo/Tuscany integration code again. I think that adding a composite to the domain does not necessarily imply download that composite to the Tuscany-enabled container that runs the components it describes. In other words I'm hoping that we can add to the domain a composite that describes an application without having to install the Tuscany Java runtime to the container that runs it. That's one of the reasons why I brought up that scenario: To help us explore what a domain really is and the idea that an SCA domain is more than a bunch of Tuscany-Java runtimes that use a Tuscany-specific protocol to advertise/discover their services. I have been working on bringing the Geronimo plugin back up again with the code in trunk and that is almost done now so we have some options about how we want to ply this. We could add the ability to introduce service descriptions to the domain regardless of whether the service is running on a Tuscany enabled endpoint although I haven't done this yet. We need to agree how this would be achieved from the users point of view. For example, is this a specific interface for associating the domain with existing services or is it to use the existing contribution interfaces with composites marked in some way that indicates that they are not to be deployed for real but simply added to the domain. Generally we need the ability on the domain to view and manipulate component definitions so that the deployment process is more flexible for situations when the domain level composite is modified. The deployment of virtual components could be part of this. I'll have a play this morning and see if any inspiration comes. I have spent time bringing up the Geronimo plugin to work with the code in trunk so we can play with a number of different scenarios. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wendy Hsu is out of the office for vacation
I will be out of the office starting 12/05/2007 and will not return until 12/31/2007. I will respond to your message when I return.
[jira] Created: (TUSCANY-1931) New WireTestCase in order to detect bug reported in JIRA as TUSCANY-1930
New WireTestCase in order to detect bug reported in JIRA as TUSCANY-1930 Key: TUSCANY-1931 URL: https://issues.apache.org/jira/browse/TUSCANY-1931 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1, Java-SCA-1.1 Reporter: Andy Verberne The current WireTestCase does not detect a bug which exists in the Assembly Module. This bug is reported in Jira as TUSCANY-1930 The WireTestCase should be expanded to test a wire where the component and service name specified as the target (i.e. target=WireServiceComponent/WireService) are different. The current test only tests the case where they are equal (i.e. target=WireService/WireService). -- 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: Data transformation from/to POJO
Raymond Feng wrote: Hi, I have checked in the first cut under http://svn.apache.org/viewvc?rev=601501view=rev. With these changes, we now use JAXB databinding to deal with POJOs (including simple and complex types). By the JAXB Java to XML default mapping, POJOs are supported in line with the JavaBeans patterns with the flowing rules. 1) There is a protected or public no-arg constructor 2) A property is either a public field or public setter getter. Even for Collection type, the setter is required. 3) The property can not be an interface 4) Circular object reference is not supported 5) References to the same object are flattened One caveat is that it brings the jaxb-api and jaxb-impl as core dependencies (about 1MB). We could try to implement the default Java/XML mapping by ourselves if that's desirable. There are also other things we need to improve, for example, how to render a JAXB object as XMLStreamReader. The quick and dirty way is to marshal the JAXB object into a byte array and create XMLStreamReader out of it. We could even use the fast-infoset to help the performance of the round trip. Thanks, Raymond Great Thanks! Now that we have the external behavior right I should be able to clean up the store scenario. +1 for improving and optimizing the implementation over time. If anybody is interested it would be nice to get concrete performance numbers at some point, analyze the numbers and define performance objectives. This should help understand what needs to be optimized. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Webapp integration test with maven cargo plugin
Hi, We have been painful with running the web application tests manually a few days before a release. I think it would be beneficial to automate the tests as part of the maven build. To get it started, I checked in [1] an example to demonstrate how to use the cargo [2] maven plugin to automate the integration test of Tuscany web applications. The maven build now goes with the following steps: 1) package: generate the artifacts as a WAR 2) pre-integration-test: start the Jetty web server (embedded or external) and deploy the WAR to the server using Cargo 3) integration-test: run the integration test cases using surefire plugin. The test case should be the client program that talks to the web app 4) post-integration-test: stop the Jetty web server using Cargo Thanks, Raymond [1] http://svn.apache.org/viewvc?rev=601610view=rev [2] http://cargo.codehaus.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
