Re: SCDL extensions to define data types for parameters and return value
Hi,
I don't see much difference to define DataTypes for WSDL portTypes than java
interfaces.
If we look at the WSDL structure, we can define default DataType for a
portType, an operation or a part.
portType
operation
input: message
part
output: message
part
fault: message
part
Usually, the part is typed by XSD. So it makes sense to have the DataType
such as SDO, JAXB, and XmlBeans.
An example may look like (for illustration only):
interface.wsdl ...
...
tuscany:databinding
xmlns:tuscany=http://tuscany.apache.org/xmlns/1.0-SNAPSHOT; dataType=sdo
!-- default to sdo for the portType --
operation name=getCreditReport dataType=sdo !-- default to
sdo for the operation --
!-- more fine control --
input
part index=0
dataType name=sdo
xmlType={http://customer}Customer/
/part
/input
output
part index=0
dataType name=sdo
xmlType={http://credit}CreditReport; javaClass=...'/
/part
/output
/operation
/tuscany:databinding
/interface.wsdl
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, August 24, 2006 1:39 AM
Subject: Re: SCDL extensions to define data types for parameters and return
value
What about when you're using interface.wsdl and things like JavaScript?
Take
the following composite example, could you show what the additional SCDL
extension would be needed to get that to work with SDO and E4X?
composite ...
service name=MyHelloWorldWebService ...
interface.wsdl.../
binding.ws.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference name=helloWorldServiceHelloWorldService/reference
/references
/component
reference name=HelloWorldService
interface.wsdl.../
binding.ws.../
/reference
/composite
Thanks,
...ant
On 8/23/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I think we have several use cases here:
Case 1: Invoking a web service using a SCA reference with Axis2 binding
composite ...
reference name=creditReport
interface.java interface=sample.CreditReportService/
/reference
...
/composite
Source DataType is controlled by the application (it can be either
decorated
by SCDL extensions or introspected from the value. For example, the
Customer
can be a SDO or JAXB object). I see the requirement that the DataType be
specified at parameter/return value level for a given operation. I'm not
sure at which level where the default databinding should be set,
interface,
or composite?
Target DataType is controlled by the binding. Axis2 WebService binding
uses
AXIOM. We need a way for the binding builder to tell Tuscany runtime the
DataTypes it can support for references and services.
Case 2: SCA service with web service binding delegates the invocation to
a
POJO component
composite ...
service name=creditReportService
interface.java interface=sample.CreditReportService/
referenceCreditReportComponent/reference
/service
component name=CreditReportComponent
implementation.java class=sample.CreditReportServiceImpl/
...
/composite
In this case, the Axis2 binding gets AXIOM data and it's now ready to
invoke
the target POJO component.
Source DataType will be AXIOM.
Target DataType will be controlled by the POJO component implementation
which can choose to use SDO, JAXB, or OMElement to receive the
parameters.
The metadata can be extracted from SCDL, java annotations or
introspection.
Case 3: One component invokes another component in the same composite
Both source DataType and target DataType are controlled by the
application.
With the databinding, do we want to extend the concept of compatible
interfaces? For example, the component1.reference1 is wired to
component2.service1. component1.reference1 is typed by interface
CreditReportService1 while component2.service1 by CreditReportService2.
We
assume that CustomerSDO can be transformed to CustomerJAXB, same for
CreditReportJAXB to CreditReportSDO.
public interface CreditReportService1 {
public CreditReportSDO getCreditReport(CustomerSDO customer);
}
public interface CreditReportService2 {
public CreditReportJAXB getCreditReport(CustomerJAXB customer);
}
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, August 22, 2006 7:12 AM
Subject: Re: SCDL extensions to define data types for parameters and
return
value
Could you give a bit more detail and a few more complete examples, I'm
not
sure I understand all this? It seems a lot of XML, you're not likely to
use
[PROPOSAL] Add tuscany- as the prefix for our artifact ids
Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add tuscany- as a prefix to the artifactId. Do you agree? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add tuscany- as the prefix for our artifact ids
+1 Rick also suggested this a while back, maybe we should raise a JIRA this time so its not forgotten. ...ant On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add tuscany- as a prefix to the artifactId. Do you agree? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCDL extensions to define data types for parameters and return value
What I'm trying to see is the minimum needed to get assemblies going with
different data bindings. One difference with using WSDL portTypes is that
you can't use introspection or annotations so all the config needs to be
done in the SCDL. I'm also wondering about the config for the source and
target ends of the wires which is why the example i asked about earlier had
a service wired to a component wired to a reference. Could you use that
example and show what is the minimum necessary to get it working with the
new data binding framework?
...ant
On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I don't see much difference to define DataTypes for WSDL portTypes than
java
interfaces.
If we look at the WSDL structure, we can define default DataType for a
portType, an operation or a part.
portType
operation
input: message
part
output: message
part
fault: message
part
Usually, the part is typed by XSD. So it makes sense to have the DataType
such as SDO, JAXB, and XmlBeans.
An example may look like (for illustration only):
interface.wsdl ...
...
tuscany:databinding
xmlns:tuscany=http://tuscany.apache.org/xmlns/1.0-SNAPSHOT;
dataType=sdo
!-- default to sdo for the portType --
operation name=getCreditReport dataType=sdo !-- default to
sdo for the operation --
!-- more fine control --
input
part index=0
dataType name=sdo
xmlType={http://customer}Customer/
/part
/input
output
part index=0
dataType name=sdo
xmlType={http://credit}CreditReport; javaClass=...'/
/part
/output
/operation
/tuscany:databinding
/interface.wsdl
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, August 24, 2006 1:39 AM
Subject: Re: SCDL extensions to define data types for parameters and
return
value
What about when you're using interface.wsdl and things like JavaScript?
Take
the following composite example, could you show what the additional SCDL
extension would be needed to get that to work with SDO and E4X?
composite ...
service name=MyHelloWorldWebService ...
interface.wsdl.../
binding.ws.../
referenceHelloWorldComponent/reference
/service
component name=HelloWorldComponent
js:implementation.js script=HelloWorld.js/
references
reference
name=helloWorldServiceHelloWorldService/reference
/references
/component
reference name=HelloWorldService
interface.wsdl.../
binding.ws.../
/reference
/composite
Thanks,
...ant
On 8/23/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I think we have several use cases here:
Case 1: Invoking a web service using a SCA reference with Axis2 binding
composite ...
reference name=creditReport
interface.java interface=sample.CreditReportService/
/reference
...
/composite
Source DataType is controlled by the application (it can be either
decorated
by SCDL extensions or introspected from the value. For example, the
Customer
can be a SDO or JAXB object). I see the requirement that the DataType
be
specified at parameter/return value level for a given operation. I'm
not
sure at which level where the default databinding should be set,
interface,
or composite?
Target DataType is controlled by the binding. Axis2 WebService binding
uses
AXIOM. We need a way for the binding builder to tell Tuscany runtime
the
DataTypes it can support for references and services.
Case 2: SCA service with web service binding delegates the invocation
to
a
POJO component
composite ...
service name=creditReportService
interface.java interface=sample.CreditReportService/
referenceCreditReportComponent/reference
/service
component name=CreditReportComponent
implementation.java class=sample.CreditReportServiceImpl/
...
/composite
In this case, the Axis2 binding gets AXIOM data and it's now ready to
invoke
the target POJO component.
Source DataType will be AXIOM.
Target DataType will be controlled by the POJO component implementation
which can choose to use SDO, JAXB, or OMElement to receive the
parameters.
The metadata can be extracted from SCDL, java annotations or
introspection.
Case 3: One component invokes another component in the same composite
Both source DataType and target DataType are controlled by the
application.
With the databinding, do we want to extend the concept of compatible
interfaces? For example, the component1.reference1 is wired to
component2.service1. component1.reference1 is typed by interface
CreditReportService1 while component2.service1 by CreditReportService2.
We
assume that CustomerSDO can be
Re: [PROPOSAL] Add tuscany- as the prefix for our artifact ids
I agree that the names are confusing. Would you like to see more meaningful names like tuscany-binding-axis2-1.0-SNAPSHOT.jar tuscany-sca-api-1.0-SNAPSHOT.jar tuscany-sca-core-1.0-SNAPSHOT.jar ... tuscany-idl-wsdl-1.0-SNAPSHOT.jar etc. ? On 8/25/06, ant elder [EMAIL PROTECTED] wrote: +1 Rick also suggested this a while back, maybe we should raise a JIRA this time so its not forgotten. ...ant On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add tuscany- as a prefix to the artifactId. Do you agree? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-666) Java SCA: A non-blocking asynchronous HTTP transport
Java SCA: A non-blocking asynchronous HTTP transport Key: TUSCANY-666 URL: http://issues.apache.org/jira/browse/TUSCANY-666 Project: Tuscany Issue Type: New Feature Reporter: ant elder Priority: Minor Fix For: Wish list It would be cool to have a non-blocking asynchronous HTTP transport. We could use that for things like async web services and ajax. The easiest way to do it would be using Asyncweb (http://asyncweb.safehaus.org/), although there's also the HTTPComponents project but that doesn't seem so far along: http://jakarta.apache.org/httpcomponents/. For how to do it look at the existing Tuscany synchronous HTTP support using ServletHost and the Jetty based HTTP transport: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/host/ServletHost.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/java/org/apache/tuscany/runtime/webapp/ServletHostImpl.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/transports/http.jetty/ Along with the Asyncweb doc there are examples of using it in Synapse and XFire: http://svn.apache.org/repos/asf/incubator/synapse/trunk/java/modules/nhttp/ http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire-sandbox/xfire-asyncweb -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-417) Interactive JavaScript SCA client
[ http://issues.apache.org/jira/browse/TUSCANY-417?page=all ] ant elder updated TUSCANY-417: -- Fix Version/s: Java-Mx (was: Java-M2) Affects Version/s: Java-Mx (was: Java-M2) Interactive JavaScript SCA client - Key: TUSCANY-417 URL: http://issues.apache.org/jira/browse/TUSCANY-417 Project: Tuscany Issue Type: New Feature Components: Java SCA JavaScript Container Affects Versions: Java-Mx Reporter: ant elder Assigned To: ant elder Fix For: Java-Mx Attachments: TuscanyShell.zip Create a new JavaScript SCA client shell similar to the Rhino shell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-421) Support externalServices with the jsonrpc binding
[ http://issues.apache.org/jira/browse/TUSCANY-421?page=all ] ant elder updated TUSCANY-421: -- Fix Version/s: Java-Mx (was: Java-M2) Affects Version/s: Java-Mx (was: Java-M2) Moving to Mx for now. There is a version of the binding that does this based on DWR in the sandbox, but it needs porting to the new code base: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/ Support externalServices with the jsonrpc binding - Key: TUSCANY-421 URL: http://issues.apache.org/jira/browse/TUSCANY-421 Project: Tuscany Issue Type: Improvement Components: Java SCA JsonRpc Binding Affects Versions: Java-Mx Reporter: ant elder Fix For: Java-Mx Support SCA externalServices doing whats known as comet or reverse ajax. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-87) Support pluggable data binding in the Axis2 WS binding
[ http://issues.apache.org/jira/browse/TUSCANY-87?page=all ] ant elder closed TUSCANY-87. Resolution: Duplicate This has been superseeded by TUSCANY-541 Support pluggable data binding in the Axis2 WS binding -- Key: TUSCANY-87 URL: http://issues.apache.org/jira/browse/TUSCANY-87 Project: Tuscany Issue Type: New Feature Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: ant elder Priority: Critical Fix For: Java-Mx Currently the Axis2 impl of the WS binding always uses SDO for serialization/de-serialization. Enable supporting other technologies such as the Axis2 ADB, Xmlbeans etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ] ant elder closed TUSCANY-61. Fix Version/s: Java-M2 (was: Java-Mx) Resolution: Fixed Assignee: ant elder (was: Raymond Feng) Works on the new code base ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: ant elder Assigned To: ant elder Fix For: Java-M2 Attachments: patch.txt Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-104) Support efficient (de)serilization and streaming with the WS binding
[ http://issues.apache.org/jira/browse/TUSCANY-104?page=all ] ant elder closed TUSCANY-104. - Resolution: Duplicate Superseeded by TUSCANY-541 Support efficient (de)serilization and streaming with the WS binding Key: TUSCANY-104 URL: http://issues.apache.org/jira/browse/TUSCANY-104 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: ant elder Fix For: Java-Mx Support efficient (de)serilization and streaming between components/services. Ideally so you can wire up a WS entryPoint to an externalService or e4x or XSLT component and have the SOAP body pulled directly from the incoming StaX stream. This will probably require changes to more than just the binding.axis2 code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-271) Sort out what Tuscany does/requires for the axis2.xml
[ http://issues.apache.org/jira/browse/TUSCANY-271?page=all ] ant elder updated TUSCANY-271: -- Fix Version/s: Java-M2 (was: Java-Mx) Affects Version/s: Java-M2 (was: Java-Mx) Sort out what Tuscany does/requires for the axis2.xml - Key: TUSCANY-271 URL: http://issues.apache.org/jira/browse/TUSCANY-271 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M2 How the axis2.xml config worked changed a bit since 0.95 so I've commentted out that bit of code and it now just uses the default config provided wih Axis2. Should look at this and see if we need our own defaults and also if we need a way to pick up app specific config with an axis2.xml bundled with the web app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-118) Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=all ] ant elder closed TUSCANY-118. - Resolution: Fixed Partly done and the rest will be fixed with TUSCANY-541 Adding Serializer/Deserializer for DataObject using StAX for better Axis2 AXIOM integration --- Key: TUSCANY-118 URL: http://issues.apache.org/jira/browse/TUSCANY-118 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding, Java SDO Implementation Affects Versions: Java-Mx Reporter: Raymond Feng Assigned To: Frank Budinsky Fix For: Java-Mx Attachments: rfeng_sdo_stax.diff, rfeng_stax.diff, rfeng_stax_axis_095.diff Here are the key classes: 1) DataObjectStAXWrapper Implements org.apache.axis2.databinding.ADBBean interface by feeding elements and attibutes to org.apache.axis2.databinding.utils.ADBPullParser. It can be used as a Serializer for DataObject to be serialized as OMElement. 2) StAXXMLResourceImpl and StAX2SAXAdapter StAXXMLResourceImpl extends org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl to provide additional methods to load DataObject directly from XMLStreamReader. StAX2SAXAdpter is responsible to pull StAX events from XMLSreamReader and generate SAX events so that they can be consumed by XMLResourceImpl. 3) DataObjectStAXWrapperTestCase It tests the round trip for DataObject -- OMElment -- DataObject. Both static SDO model (pre-generated) and dynamic SDO model (loaded from WSDL/XSD) are covered. It also test the cost of the optimized roundtrip against the old quick and dirty way (DataObject -- OutputStream -- InputStream -- OMElement -- OutputStream -- InputStream -- DataObject). It shows more that 400% performance gain. It seems that files in set 1 and 2 are more fit to be included in the SDO sub-project. The following helper method is desirable. void SDOUtil.load(TypeHelper scope, XMLStreamReader reader, Object options) XMLStreamReader SDOUtil.save(TypeHelper scope, XMLDocument document, Object options) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-541) support pluggable databinding and data transformation
[ http://issues.apache.org/jira/browse/TUSCANY-541?page=comments#action_12430475 ] ant elder commented on TUSCANY-541: --- See some old JIRAs: TUSCANY-87, TUSCANY-104, TUSCANY-118 support pluggable databinding and data transformation - Key: TUSCANY-541 URL: http://issues.apache.org/jira/browse/TUSCANY-541 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-M2 Reporter: Raymond Feng Assigned To: Raymond Feng Fix For: Java-M2 Attachments: 541.txt, rfeng-databinding-patch-0728.txt, tuscany-databinding-trunk.zip, Tuscany-DataBinding.ppt There are a few cases behind this feature: 1) Application developers may use different data binding technologies 2) Various SCA binding requires to marshal/unmarshal data to/from different formats (for example, SDO -- Axiom) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-372) Null pointer for axis2/tomcat example where the service interface/operation takes no parameters
[ http://issues.apache.org/jira/browse/TUSCANY-372?page=all ] ant elder closed TUSCANY-372. - Resolution: Fixed Null pointer for axis2/tomcat example where the service interface/operation takes no parameters --- Key: TUSCANY-372 URL: http://issues.apache.org/jira/browse/TUSCANY-372 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-Mx Environment: Fedora Core 5 Reporter: Simon Laws Fix For: Java-Mx Attachments: helloworld6-notworkingsample.tar, helloworld7-workingsample.tar This is based on a check out from last week so I will give it a go on the latest release but lest I forget the details. I have an example (attached) which simply calls a remote component via axis2/web services. The implemented operation takes no parameters and causes a null pointers exception down in the Axis code on the server side where the request message is being unpacked [1]. I copied the example and changed the operation signature to include a single string parameter (also included) and all was well. Nothing else, as far as I can tell, changed between the two versions of the sample. [1] [EMAIL PROTECTED] helloworld6client]$ ./run.sh Exception in thread main org.osoa.sca.ServiceRuntimeException: org.apache.axis2.AxisFault: null; nested exception is: java.lang.NullPointerException at org.apache.tuscany.binding.axis2.externalservice.Axis2ServiceInvoker.invoke(Axis2ServiceInvoker.java:56) at org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.doInvoke(ExternalServiceTargetInvoker.java:84) at org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.invokeTarget(ExternalServiceTargetInvoker.java:79) at org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.invoke(ExternalServiceTargetInvoker.java:93) at org.apache.tuscany.core.wire.impl.InvokerInterceptor.invoke(InvokerInterceptor.java:39) at org.apache.tuscany.core.wire.jdk.JDKInvocationHandler.invoke(JDKInvocationHandler.java:112) at $Proxy13.getResponse(Unknown Source) at org.sample.helloworld.HelloWorldClient.main(HelloWorldClient.java:28) Caused by: org.apache.axis2.AxisFault: null; nested exception is: java.lang.NullPointerException at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:287) at org.apache.tuscany.binding.axis2.externalservice.Axis2OperationInvoker.invokeOperation(Axis2OperationInvoker.java:78) at org.apache.tuscany.binding.axis2.externalservice.Axis2ServiceInvoker.invoke(Axis2ServiceInvoker.java:53) ... 7 more Caused by: java.lang.Exception: org.apache.axis2.AxisFault: null; nested exception is: java.lang.NullPointerException at org.apache.axis2.AxisFault.makeFault(AxisFault.java:318) at org.apache.tuscany.binding.axis2.entrypoint.WebServiceEntryPointInOutSyncMessageReceiver.invokeBusinessLogic(WebServiceEntryPointInOutSyncMessageReceiver.java:83) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:37) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136) at org.apache.tuscany.binding.axis2.entrypoint.WebServiceEntryPointServlet.doPost(WebServiceEntryPointServlet.java:81) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.tuscany.tomcat.TuscanyValve.invoke(TuscanyValve.java:87) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at
[jira] Updated: (TUSCANY-76) Need a specifcation of how WSDL elements used in an SCA assembly get resolved
[ http://issues.apache.org/jira/browse/TUSCANY-76?page=all ] ant elder updated TUSCANY-76: - Fix Version/s: Java-M2 (was: Java-Mx) Affects Version/s: Java-M2 (was: Java-Mx) Need a specifcation of how WSDL elements used in an SCA assembly get resolved -- Key: TUSCANY-76 URL: http://issues.apache.org/jira/browse/TUSCANY-76 Project: Tuscany Issue Type: New Feature Components: Specification Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: Michael John Edwards Fix For: Java-M2 The SCA 0.9 assembly spec references WSDL portTypes and ports by namespace + local name. The specification does not make any statement about how an SCA runtime or SCA tooling is supposed to resolve these WSDL elements. I think we have a number of options here: - define name mapping rules between WSDL namespaces and names and WSDL file locations, allowing a runtime and tooling to derive the location of the WSDL files from their namespaces for example (similar to the Java package - location mapping rules) - introduce a way to associate a WSDL namespace to a particular file or collection of files (similar to a WSDL import) As a temporary solution until the spec resolves this issue, In Tuscany we have introduced an SCDL extension for this. The app developer must add a import.wsdl namespace=namespace of the particular wsdl location=location of wsdl file element to his sca.module, sca.fragment or sca.subsystem SCA assembly file. The import.wsdl element makes the referenced WSDL available within the scope of the particular SCA assembly. The BigBank sample contains an example of this. This Tuscany extension can be used to cover most scenarios for now but will not address well scenarios where you want to share a .componentType that uses a WSDL portType in two different modules. You'd have to repeat the same wsdl.import in the two modules. So we need the SCA assembly spec to address this issue and then adjust our implementation to what the spec will define. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-611) RMI Binding
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ] ant elder closed TUSCANY-611. - Resolution: Fixed All these patches applied now, thanks for all the patches Venkat. I'm going to close this JIRA now and new work can go in new JIRAs RMI Binding --- Key: TUSCANY-611 URL: http://issues.apache.org/jira/browse/TUSCANY-611 Project: Tuscany Issue Type: Bug Affects Versions: Java-M2 Reporter: Venkatakrishnan Assigned To: ant elder Fix For: Java-M2 Attachments: binding_rmi.zip, Tuscany-RMI-Binding-Aug-10-Updated.diff, Tuscany-RMI-Binding-Aug-10.diff, Tuscany-RMI-Binding-Formatted-Aug-15-1.diff, Tuscany-RMI-Binding-Reference-Sample-Aug-10.diff, Tuscany-RMI-Binding-Service-Sample-Aug-10.diff, Tuscany-RMI-Binding-Updated-Aug-15-2.diff, Tuscany-SCA-SPI-Aug-15.diff SCA RMI Binding with samples for SCA Reference and SCA Service using RMI Binding. Here is a first cut implementation for this. Could somebody please review and apply? Also I have had the following issues un-resolved: - - The samples can be tested thro the Testcases in them. These testcases work from eclipse as long as I have added the RMI-Binding Eclipse project to the classpath. Otherwise the binding does get picked up. The same is the issue when trying to execute the testcases from maven. Could somebody please help in fixing this? Thanks. Note :- I shall be working further with this binding to address the following : - - there is single attribute called 'uri' for the binding. I shall be splitting this to host, port and service name with defaults to each when not specified. - it is now required the that SCA Service require a component to implement the interface Remote. I imagine this to be intrusive. All that a developer should do is pick up an existing component with a 'non remote' interface and simply deploy it exposing the service as RMI. The binding should dynamically be able to generate a remote interface and a proxy and host it as a facade to this implementation. - will be glad to take forward any other inputs from the community as well. Thanks - Venkat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO for C++} Review of JIRA status
I've applied all of these now and all seems fine. Cheers, On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote: Pete, Thanks for that, all the ones with applied patches have been closed. That leaves four with patches waiting to be applied 490: patch submitted but not yet applied 496: patch submitted but not yet applied 539: patch submitted but not yet applied 553: patch submitted but not yet applied Could you look at those too? Thanks in advance. Geoff. On 04/08/06, Pete Robbins [EMAIL PROTECTED] wrote: Geoff, I'll go through, verify, then close the Jiras that are fixed. I'll take a look at the patches that have not been applied as well. Cheers, -- Pete
[jira] Resolved: (TUSCANY-490) DataObjectPtr::getByte returns incorrect data
[ http://issues.apache.org/jira/browse/TUSCANY-490?page=all ]
Pete Robbins resolved TUSCANY-490.
--
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
DataObjectPtr::getByte returns incorrect data
-
Key: TUSCANY-490
URL: http://issues.apache.org/jira/browse/TUSCANY-490
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Andrew Borley
Priority: Minor
Fix For: Cpp-current
Attachments: TUSCANY-490.patch
Some xml like byte123/byte where the byte element contains an xsd:byte
type, is converted into a DataObject and then queried.
// returns the correct data: 123
const char* cs = myDataObjectPtr-getCString(byte);
// Returns incorrect data: '1' (Ox31) - looks like it's just taking the
first character, rather than converting 123 to the character '{' (Ox7B)
char c = myDataObjectPtr-getByte(byte);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-553) Add a static null SDOString to the SDOString class
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ] Pete Robbins resolved TUSCANY-553. -- Fix Version/s: Cpp-current Resolution: Fixed patch applied Add a static null SDOString to the SDOString class -- Key: TUSCANY-553 URL: http://issues.apache.org/jira/browse/TUSCANY-553 Project: Tuscany Issue Type: Improvement Components: C++ SDO Affects Versions: Cpp-current Environment: Windows and Linux Reporter: Geoff Winn Priority: Minor Fix For: Cpp-current Attachments: TUSCANY-553.patch It is frequently necessary to create null strings as default parameters or to represent enmpty return values. Where these values are read only they can be references to a single class static. Add this static to the class for later use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Add tuscany- as the prefix for our artifact ids
I brought it up a few times on the IRC, but it didn't seem anyone was interested. Once you start working with other projects it becomes a bit of a pain distinguish them. Especially, our axis binding looks more like it would belong to axis and not Tuscany. There is a concern that these names do find themselves in war, and jars produced so it can make them a bit long. ant elder wrote: +1 Rick also suggested this a while back, maybe we should raise a JIRA this time so its not forgotten. ...ant On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is a list of JARs we're building: axis2-1.0-SNAPSHOT.jar spring-1.0-SNAPSHOT.jar celtix-1.0-SNAPSHOT.jar groovy-1.0-SNAPSHOT.jar rmi-1.0-SNAPSHOT.jar api-1.0-SNAPSHOT.jar core-1.0-SNAPSHOT.jar spi-1.0-SNAPSHOT.jar wsdl-1.0-SNAPSHOT.jar Don't we think the name of the jars are misleading? Can we tell these jars from tuscany project? The groupId makes them unique for the maven repository but it seems to be wierd when we copy these jars into some folders. I propose that we restore the naming convention we had in M1: add tuscany- as a prefix to the artifactId. Do you agree? Thanks, Raymond - 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: Avoiding extension and application scdl collisions
I'd still prefer to have extensions and system referenced from a different directory. Does the spec really mandate the file extension; I kind of preferred scdl myself Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user chooses to do so. To be consistent with the SCA spec (xxx.composite), I suggest that we have the following conventions. core: META-INF/tuscany/system.composite (with includes) extension: META-INF/tuscany/extension.composite application: META-INF/sca/application.composite Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscdev tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 9:26 AM Subject: Avoiding extension and application scdl collisions I kind of have and closer idea why interop unit testcases fail when run from the maven command line. It appears the forking for some reason I'm still not 100% sure of puts the Axis2Binding jar in the same classloader as the application scdl. It could be the fork actually has dependencies need by the testcase already on the classpath? In any case when the application scdl is being search for it is being found in the extension jar because the default resource name is the same for both extensions and application scdl (META-INF/sca/default.scdl) I can for the testcase specifically rename the application scdl to something different and it then works. To avoid this and also provide the flexibility to load in one classloader scope would having default names as follows be reasonable?: META-INF/tuscany/system/system.scdl. (system) META-INF/tuscany/extension/default.scdl (extensions) META-INF/sca/default.scdl (application) (not too sure how this plays with the SCA archive proposal) Also, I'm wondering if it is already possible, if we could add an xml attribute to system and extension scdl to identify it as such so when we are expecting one type and it does not have this attribute we throw an exception? This would have been a whole lot more helpful to me than the resulting NPE? Thought? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn properties...
To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] setprops.sh Description: application/shellscript - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn properties...
Sounds good, so you have my +1 ...ant On 8/25/06, Daniel Kulp [EMAIL PROTECTED] wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New build break
The latest update, that updates a lot of the core/implementation/processors, seems to be breaking a lot if not all of the sca samples. The way I see this is by doing a mvn clean and mvn -e from the top, which breaks while running the tests for the SDO impl, so then I go to sca/core and do mvn -e and then go to samples/sca and do mvn -e. This is where I see various exceptions from processors such as ServiceProcessor and HeuristicPojoProcessor, including NPE, from samples that used to run, such as supply chain and samplecallback. Any ideas?
Re: svn properties...
+1 to update DAS On 8/25/06, ant elder [EMAIL PROTECTED] wrote: Sounds good, so you have my +1 ...ant On 8/25/06, Daniel Kulp [EMAIL PROTECTED] wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: New site sample
I plan to have DAS contents ready by early next week. On 8/24/06, David Wheeler [EMAIL PROTECTED] wrote: Hi everyone, I think the site layout is probably in good final candidate form, but there are a few pages that need to be written that I wouldn't consider myself qualified to create. We need general overview/getting started with pages for: SCA-Java SCA-C++ SDO-C++ DAS Right now we only have a SCA-Java page that fits the description. Please look over the site and let me know if anything else is missing/wrong. -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Ruby Header-replace script
Would you like to make that available in the /etc dir where the other
scripts are ?
Thanks
- Luciano
On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote:
I think a couple of people have used this now. Here is an update ...
# Scans files - with a given extension - recursively from the current
# directory replacing the old copyright/license header statement with a
# new version
#
# Example command line usage
# ruby replaceheaders.rb java oldheader.txt newheader.txt
def munge_file(fn, oh, nh)
eoh = Regexp.escape(oh)
new_contents = File.read(fn).gsub!(Regexp.new(eoh), nh)
if new_contents
puts processing #{fn}
File.open(fn, 'w') do |file|
file.puts(new_contents)
end
$num_files_processed += 1
else
puts processing #{fn} - NO MATCH!
$num_files_no_match += 1
end
end
if(!ARGV[0])
STDERR.puts usage: file extension old header file new header
file
exit 0
end
ext = ARGV[0]
$num_files_processed = $num_files_no_match = 0
puts Scanning files with #{ext} extension
old_header = File.read(ARGV[1])
new_header = File.read(ARGV[2])
Dir[**/*.#{ext}].each do |filename|
munge_file( filename, old_header, new_header)
end
puts Total files matched and processed = #{$num_files_processed}
puts Number of files with no match = #{$num_files_no_match}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-
Luciano Resende
SOA Opensource - Apache Tuscany
-
Re: Das Logging Framework
Also, as we are planning to change our DAS logging code, we should also consider performance enhancements on that area. Today, I see various places where we are doing log like this: DebugUtil.debugln(getClass(), debug, Adding table/column: + typeName + / + propertyName); And I would recommend having something like this : if( logger.isDebugEnabled) logger.debugln(getClass(), debug, Adding table/column: + typeName + / + propertyName); The problem with current code related to performance and garbage collection, is that, even if debug is not enabled, lot's of strings are created (e.gAdding table/column: + typeName + / + propertyName) and will need to be garbage collected slowing server performance. This is a good tip for all other areas of Tuscany, altough I haven't investigated other areas in detail. - Luciano On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote: My poor choice of wording. I really meant any concerns rather than any objections. Thanks again! Jim Marino wrote: On Aug 23, 2006, at 8:05 PM, Kevin Williams wrote: Thanks for your input. I enjoyed the evils of common logging link. So, if we avoid JCL then my next suggestion would be to use either Java logging or log4j directly and our users will need to deal with the -- possibly -- separate logging system. Are there any objections to this route? Hopefully you didn't think I was objecting to using clogging (it's the DAS peoples' decision) but was just trying to save you the pain I had using that. Not knowing all of the requirements I would probably do one of the following: 1. Use log4j and for people that wanted to use DAS with another logging solution have them add an appender that pipes the information somewhere else 2. Externalize logging like SCA. The bootstrap would provide a MonitorFactory implementation that would be responsible for creating implementations of a specific logging interface. You could create an environment property that points to the factory impl to instantiate and have a constructor that takes an instance. The factory could then delegate to something else and you could have a default that uses reflection and sends everything to Log4J. This has the advantage of allowing for strongly typed logging as well as not forcing things to go through log4j (which may not be that big of a deal). Each subsystem would be responsible for using the monitor factory to create monitor implementations for particular components. Jim Thanks, --Kevin Jim Marino wrote: - 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] -- - Luciano Resende SOA Opensource - Apache Tuscany -
Re: Ruby Header-replace script
Yes. Good point. I'll put it out there.
Thanks,
--Kevin
Luciano Resende wrote:
Would you like to make that available in the /etc dir where the other
scripts are ?
Thanks
- Luciano
On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote:
I think a couple of people have used this now. Here is an update ...
# Scans files - with a given extension - recursively from the current
# directory replacing the old copyright/license header statement with a
# new version
#
# Example command line usage
# ruby replaceheaders.rb java oldheader.txt newheader.txt
def munge_file(fn, oh, nh)
eoh = Regexp.escape(oh)
new_contents = File.read(fn).gsub!(Regexp.new(eoh), nh)
if new_contents
puts processing #{fn}
File.open(fn, 'w') do |file|
file.puts(new_contents)
end
$num_files_processed += 1
else
puts processing #{fn} - NO MATCH!
$num_files_no_match += 1
end
end
if(!ARGV[0])
STDERR.puts usage: file extension old header file new header
file
exit 0
end
ext = ARGV[0]
$num_files_processed = $num_files_no_match = 0
puts Scanning files with #{ext} extension
old_header = File.read(ARGV[1])
new_header = File.read(ARGV[2])
Dir[**/*.#{ext}].each do |filename|
munge_file( filename, old_header, new_header)
end
puts Total files matched and processed = #{$num_files_processed}
puts Number of files with no match = #{$num_files_no_match}
-
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: Avoiding extension and application scdl collisions
On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user chooses to do so. Could you explain your reasons why? The only case where I can see this being a good thing for the user is if an extension offers APIs or libraries that must be accessed from the application. In that case, those APIs or libraries should be loaded in a parent to the extension classloader which is then given as a parent to the application classloader (which would be multiparent). Jim To be consistent with the SCA spec (xxx.composite), I suggest that we have the following conventions. core: META-INF/tuscany/system.composite (with includes) extension: META-INF/tuscany/extension.composite application: META-INF/sca/application.composite Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscdev tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 9:26 AM Subject: Avoiding extension and application scdl collisions I kind of have and closer idea why interop unit testcases fail when run from the maven command line. It appears the forking for some reason I'm still not 100% sure of puts the Axis2Binding jar in the same classloader as the application scdl. It could be the fork actually has dependencies need by the testcase already on the classpath? In any case when the application scdl is being search for it is being found in the extension jar because the default resource name is the same for both extensions and application scdl (META-INF/sca/default.scdl) I can for the testcase specifically rename the application scdl to something different and it then works. To avoid this and also provide the flexibility to load in one classloader scope would having default names as follows be reasonable?: META-INF/tuscany/system/system.scdl. (system) META-INF/tuscany/extension/default.scdl (extensions) META-INF/sca/default.scdl (application) (not too sure how this plays with the SCA archive proposal) Also, I'm wondering if it is already possible, if we could add an xml attribute to system and extension scdl to identify it as such so when we are expecting one type and it does not have this attribute we throw an exception? This would have been a whole lot more helpful to me than the resulting NPE? Thought? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn properties...
OK. I'm going to go ahead and do this. It seems to look pretty good and doesn't break any tests. The main problem seems to be the SDO section with a lot of files without the proper eol-style property which causes some big cleanups. Dan On Friday August 25 2006 9:35 am, Daniel Kulp wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
Hi Ignacio, The build runs fine for me. Did you try mvn clean first? Can you send a stacktrace if it persists? Jim On Aug 25, 2006, at 7:00 AM, Ignacio Silva-Lepe wrote: The latest update, that updates a lot of the core/implementation/ processors, seems to be breaking a lot if not all of the sca samples. The way I see this is by doing a mvn clean and mvn -e from the top, which breaks while running the tests for the SDO impl, so then I go to sca/core and do mvn -e and then go to samples/sca and do mvn -e. This is where I see various exceptions from processors such as ServiceProcessor and HeuristicPojoProcessor, including NPE, from samples that used to run, such as supply chain and samplecallback. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Das Logging Framework
Yes. I aggree, and this goes to our logging policy and patterns. Luciano Resende wrote: Also, as we are planning to change our DAS logging code, we should also consider performance enhancements on that area. Today, I see various places where we are doing log like this: DebugUtil.debugln(getClass(), debug, Adding table/column: + typeName + / + propertyName); And I would recommend having something like this : if( logger.isDebugEnabled) logger.debugln(getClass(), debug, Adding table/column: + typeName + / + propertyName); The problem with current code related to performance and garbage collection, is that, even if debug is not enabled, lot's of strings are created (e.gAdding table/column: + typeName + / + propertyName) and will need to be garbage collected slowing server performance. This is a good tip for all other areas of Tuscany, altough I haven't investigated other areas in detail. - Luciano On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote: My poor choice of wording. I really meant any concerns rather than any objections. Thanks again! Jim Marino wrote: On Aug 23, 2006, at 8:05 PM, Kevin Williams wrote: Thanks for your input. I enjoyed the evils of common logging link. So, if we avoid JCL then my next suggestion would be to use either Java logging or log4j directly and our users will need to deal with the -- possibly -- separate logging system. Are there any objections to this route? Hopefully you didn't think I was objecting to using clogging (it's the DAS peoples' decision) but was just trying to save you the pain I had using that. Not knowing all of the requirements I would probably do one of the following: 1. Use log4j and for people that wanted to use DAS with another logging solution have them add an appender that pipes the information somewhere else 2. Externalize logging like SCA. The bootstrap would provide a MonitorFactory implementation that would be responsible for creating implementations of a specific logging interface. You could create an environment property that points to the factory impl to instantiate and have a constructor that takes an instance. The factory could then delegate to something else and you could have a default that uses reflection and sends everything to Log4J. This has the advantage of allowing for strongly typed logging as well as not forcing things to go through log4j (which may not be that big of a deal). Each subsystem would be responsible for using the monitor factory to create monitor implementations for particular components. Jim Thanks, --Kevin Jim Marino wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
I just synced SDO and am getting the following when building from /java: junit.framework.AssertionFailedError: The expected value did not result when calling toDay after initializing with toDay. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.executeConversion(DateConversionTestCase.java:167) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.attemptConversion(DateConversionTestCase.java:148) at org.apache.tuscany.sdo.test.DateConversionTestCase.testConversionsFromDa y(DateConversionTestCase.java:200) I would be surprised if this is from any of the changes to SCA. Jim On Aug 25, 2006, at 9:08 AM, Jim Marino wrote: Hi Ignacio, The build runs fine for me. Did you try mvn clean first? Can you send a stacktrace if it persists? Jim On Aug 25, 2006, at 7:00 AM, Ignacio Silva-Lepe wrote: The latest update, that updates a lot of the core/implementation/ processors, seems to be breaking a lot if not all of the sca samples. The way I see this is by doing a mvn clean and mvn -e from the top, which breaks while running the tests for the SDO impl, so then I go to sca/core and do mvn -e and then go to samples/sca and do mvn -e. This is where I see various exceptions from processors such as ServiceProcessor and HeuristicPojoProcessor, including NPE, from samples that used to run, such as supply chain and samplecallback. Any ideas? - 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: svn properties...
Actually, I'm seeing a build failure in SDO (test failure), although it's doing that in a clean view as well.I don't have time to investigate that right now. Thus, I'm going to wait till monday to do this. I don't want to make some big changes when I know there is a failure. Dan On Friday August 25 2006 12:07 pm, Daniel Kulp wrote: OK. I'm going to go ahead and do this. It seems to look pretty good and doesn't break any tests. The main problem seems to be the SDO section with a lot of files without the proper eol-style property which causes some big cleanups. Dan On Friday August 25 2006 9:35 am, Daniel Kulp wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn properties...
I'm sure the cpp tree could also benefit from this treatment. I will own up to having Rev, Date in my subversions properties... as that is what Jeremy told me to do (he's not around so I can blame him ;-) ) Is there a definitive list of property settings to use? This is the list Jeremy gave me at the beginning of the year: One way to set these automatically is to configure them in SVN's default configuration file located at: Unix: ~/.subversion/config Windows: %APPDATA%\Subversion\config Uncomment the line that says: enable-auto-props = yes and add the following lines to the bottom: [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg Makefile = svn:eol-style=native *.java = svn:eol-style=native;svn:keywords=Rev,Date *.xml = svn:eol-style=native;svn:keywords=Rev,Date *.xsd = svn:eol-style=native;svn:keywords=Rev,Date *.html = svn:eol-style=native;svn:keywords=Rev,Date *.properties = svn:eol-style=native;svn:keywords=Rev,Date *.jelly = svn:eol-style=native;svn:keywords=Rev,Date *.ipr = svn:eol-style=native *.iml = svn:eol-style=native Clearly the Rev,Date should have been Rev Date. Anything else missing? Cheers, On 25/08/06, Daniel Kulp [EMAIL PROTECTED] wrote: Actually, I'm seeing a build failure in SDO (test failure), although it's doing that in a clean view as well.I don't have time to investigate that right now. Thus, I'm going to wait till monday to do this. I don't want to make some big changes when I know there is a failure. Dan On Friday August 25 2006 12:07 pm, Daniel Kulp wrote: OK. I'm going to go ahead and do this. It seems to look pretty good and doesn't break any tests. The main problem seems to be the SDO section with a lot of files without the proper eol-style property which causes some big cleanups. Dan On Friday August 25 2006 9:35 am, Daniel Kulp wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete
Re: svn properties...
Dan, Thanks for doing this. Can you also contribute the script to /java/etc? --Kevin Daniel Kulp wrote: OK. I'm going to go ahead and do this. It seems to look pretty good and doesn't break any tests. The main problem seems to be the SDO section with a lot of files without the proper eol-style property which causes some big cleanups. Dan On Friday August 25 2006 9:35 am, Daniel Kulp wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with porting jsonrpc binding
Ok, so the good news is that I got the binding and the sample working when modifying the webapp.system.scdl in webapp-host.jar. I decided it would be cleaner though to create my own copy of webapp.system.scdl (and call it jsonrpc.system.scdl) to put in my hello world webapp. I tried this and modified the web.xml to have context-param param-namesystemScdlPath/param-name param-value/META-INF/sca/jsonrpc.system.scdl/param-value /context-param However, this gives me a Null system SCDL URL Exception thrown. I looked at ServletLauncherListener.java and it looks like the systemScdlPath URL is being loaded with a different classloader than the applicationScdlPath which may be leading to the exception. Guess I'll just stick with hacking into webapp-host.jar for now, unless there is something I'm missing? -Bert On 8/24/06, ant elder [EMAIL PROTECTED] wrote: On 8/24/06, Bert Lamb [EMAIL PROTECTED] wrote: snip/ So just to clarify, until the extension mechanism is finalized I need be modifying scdl files in the webapp-host.jar to get my binding picked up? Thats right, or alternatively use your own version of the webapp.system.scdl file in your web app. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
On Aug 25, 2006, at 9:39 AM, Ignacio Silva-Lepe wrote: Ok, first, after mvn clean from the top and trying mvn -e from the top, I get: Then I do mvn -e from sca/core and from sca/spi and that works. Then I do mvn -e from samples/sca and I get: --- T E S T S --- Running localwire.LocalWireTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.702 sec FA ILURE! Did you also build launcher? The issue seems to be one of the system scdls was updated with a new service which the test case is using. The NPE is from not finding the system service. I plan on fixing autowire to throw an exception instead of just returning null if aautowires cannot be resolved. Can let me know if you are building the enitre /sca sub-tree? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about Message.getBody()
Hi,
I have a simple question about the Message interface.
public interface Message {
/**
* Returns the body of the message, which will be the payload or
parameters associated with the wire
*/
Object getBody();
...
}
Is the return value always an Object[]? If not, can somebody explain when
the body is not an Object[]? I cannot tell from the javadoc and I'm seeing
the PojoTargetInvoker is coded to handle these two cases.
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding extension and application scdl collisions
On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote: Hi, It's a bit challenging to run a simple SCA J2SE helloworld sample. Here's the folder structure you have to deal: helloworld --- bin: the launcher.jar, sca-api.jar and host-util.jar --- boot: core.jar, spi.jar, etc --- extension: axis2.jar (optional) helloworld.jar Then you can use the launcher to run helloworld sample. I fully understand the value of isolation for different level of code. I just have a feeling maybe it's too much for a poor J2SE user to get the basic sample working. Ah so this is referring to J2SE client (i.e. from main) and not in a managed environment. I still think this is not that big of a deal. I personally prefer to have directories where I can stick things than a huge classpath. It also avoids the pain of package collisions with application code. Embedded Jetty works like this and I've found it pretty straightforward. People will also still have to deal with SCDL anyway and that should be in a well-defined location. Having extensions in a well-defined location does not seem to be an additional burden. More importantly, if we are trying to make the use case of a single reference used by a J2SE client easier, I'd would say don't use SCA for that. Just use Axis (or some other transport) directly. Where SCA is valuable is in assembly of multiple services. I have some related questions here: 1) Is it possible to use SCA with Tuscany inside a traditional J2SE application with a flat classpath? Can you give a more detailed use case? If it is just accessing one service, or a couple, then my answer would probably be the same as above: use the transport directly, it will always be much easier. If you want to have an application with one SCA service in it wired to others, then a container needs to be deployed and it is not an J2SE application anymore, it is an SCA application running in a J2SE host. 2) Where should the dependency jars go? It includes the dependency jars for core runtime and extensions. I'm not sure I follow, what is it? 3) Can I have one extension depend on another extension? Sure, in which case we need to calculate the transitive closure of all dependencies and adjust classpaths accordingly. OSGi will do this for us. Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 8:59 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user chooses to do so. Could you explain your reasons why? The only case where I can see this being a good thing for the user is if an extension offers APIs or libraries that must be accessed from the application. In that case, those APIs or libraries should be loaded in a parent to the extension classloader which is then given as a parent to the application classloader (which would be multiparent). Jim To be consistent with the SCA spec (xxx.composite), I suggest that we have the following conventions. core: META-INF/tuscany/system.composite (with includes) extension: META-INF/tuscany/extension.composite application: META-INF/sca/application.composite Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscdev tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 9:26 AM Subject: Avoiding extension and application scdl collisions I kind of have and closer idea why interop unit testcases fail when run from the maven command line. It appears the forking for some reason I'm still not 100% sure of puts the Axis2Binding jar in the same classloader as the application scdl. It could be the fork actually has dependencies need by the testcase already on the classpath? In any case when the application scdl is being search for it is being found in the extension jar because the default resource name is the same for both extensions and application scdl (META-INF/sca/ default.scdl) I can for the testcase specifically rename the application scdl to something different and it then works. To avoid this and also provide the flexibility to load in one classloader scope would having default names as follows be reasonable?: META-INF/tuscany/system/system.scdl. (system) META-INF/tuscany/extension/default.scdl (extensions) META-INF/sca/default.scdl (application) (not too sure how this plays with the SCA archive proposal) Also, I'm wondering if it is already possible, if we could add an xml attribute to system and extension scdl to identify it as such so when we are expecting one type and it does not have this attribute we throw an
Re: New build break
Ok, trying to build the sca tree I get: Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.782 sec FA ILURE! testInvokeService(org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase) Time elapsed: 0.772 sec ERROR! java.lang.NoClassDefFoundError: org/apache/axiom/om/util/StAXUtils at org.apache.axis2.deployment.DescriptionBuilder.buildOM(DescriptionBui lder.java:81) at org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConf igBuilder.java:63) at org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguratio n(DeploymentEngine.java:667) at org.apache.axis2.deployment.URLBasedAxisConfigurator.getAxisConfigura tion(URLBasedAxisConfigurator.java:52) at org.apache.axis2.context.ConfigurationContextFactory.createConfigurat ionContext(ConfigurationContextFactory.java:61) at org.apache.tuscany.binding.axis2.util.TuscanyAxisConfigurator.getConf igurationContext(TuscanyAxisConfigurator.java:40) at org.apache.tuscany.binding.axis2.Axis2Reference.createServiceClient(A xis2Reference.java:98) at org.apache.tuscany.binding.axis2.Axis2Reference.init(Axis2Reference .java:71) at org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase.createAxis2Re ference(Axis2ReferenceTestCase.java:74) at org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase.testInvokeSer vice(Axis2ReferenceTestCase.java:45) when trying to build the binding for Axis2. After that, tryng to build the launcher I get: [INFO] Scanning for projects... [INFO] - --- [INFO] Building Apache Tuscany SCA Application Launcher [INFO]task-segment: [install] [INFO] - --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://www.ibiblio.org/maven2/org/apache/tuscany/hostutil/1.0-SNAPS HOT/hostutil-1.0-SNAPSHOT.pom [WARNING] Unable to get resource from repository ibiblio (http://www.ibiblio.org /maven2) Downloading: http://www.ibiblio.org/maven2/org/apache/tuscany/hostutil/1.0-SNAPS HOT/hostutil-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository ibiblio (http://www.ibiblio.org /maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany -DartifactId=hostuti l \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:launcher:jar:1.0-SNAPSHOT 2) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany:launcher:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), ibiblio (http://www.ibiblio.org/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany -DartifactId=hostuti l \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:launcher:jar:1.0-SNAPSHOT 2) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany:launcher:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), ibiblio (http://www.ibiblio.org/maven2) Notice I try this several times but it makes no difference. After that, trying to build samples/sca, I do get past local.wire, but then I get: [INFO] - --- [INFO] Building Tuscany HelloWorld Web Service Sample [INFO]task-segment: [install] [INFO] - --- [INFO] artifact org.apache.maven.plugins:maven-war-plugin: checking for updates from apache-snapshot-repository [INFO] snapshot org.apache.maven.plugins:maven-war-plugin:2.0.1-SNAPSHOT: checki ng for updates from apache-snapshot-repository [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources.
Re: New build break
I'm going to send out a separate mail dealing with how to solve the issues you are seeing long term as I think we are witnessing the results of not having the correct level of modularity in the build. In the meantime, comments below on how to solve this. On Aug 25, 2006, at 10:30 AM, Ignacio Silva-Lepe wrote: Ok, trying to build the sca tree I get: Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.782 sec FA ILURE! testInvokeService (org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase) Time elapsed: 0.772 sec ERROR! java.lang.NoClassDefFoundError: org/apache/axiom/om/util/StAXUtils at org.apache.axis2.deployment.DescriptionBuilder.buildOM (DescriptionBui lder.java:81) at org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConf igBuilder.java:63) at org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguratio n(DeploymentEngine.java:667) at org.apache.axis2.deployment.URLBasedAxisConfigurator.getAxisConfigura tion(URLBasedAxisConfigurator.java:52) at org.apache.axis2.context.ConfigurationContextFactory.createConfigurat ionContext(ConfigurationContextFactory.java:61) at org.apache.tuscany.binding.axis2.util.TuscanyAxisConfigurator.getConf igurationContext(TuscanyAxisConfigurator.java:40) at org.apache.tuscany.binding.axis2.Axis2Reference.createServiceClient(A xis2Reference.java:98) at org.apache.tuscany.binding.axis2.Axis2Reference.init (Axis2Reference .java:71) at org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase.createAxis2Re ference(Axis2ReferenceTestCase.java:74) at org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase.testInvokeSer vice(Axis2ReferenceTestCase.java:45) I have that issue as well. It appears to be a problem with the snapshot versions of Axis and Axiom being out of sync. Apparently we had to move to snapshot due to issues with Axis/Axiom loading artifacts using the current context classloader. when trying to build the binding for Axis2. After that, tryng to build the launcher I get: [INFO] Scanning for projects... [INFO] -- --- --- [INFO] Building Apache Tuscany SCA Application Launcher [INFO]task-segment: [install] [INFO] -- --- --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://www.ibiblio.org/maven2/org/apache/tuscany/ hostutil/1.0-SNAPS HOT/hostutil-1.0-SNAPSHOT.pom [WARNING] Unable to get resource from repository ibiblio (http:// www.ibiblio.org /maven2) Downloading: http://www.ibiblio.org/maven2/org/apache/tuscany/ hostutil/1.0-SNAPS HOT/hostutil-1.0-SNAPSHOT.jar [WARNING] Unable to get resource from repository ibiblio (http:// www.ibiblio.org /maven2) [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany - DartifactId=hostuti l \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:launcher:jar:1.0-SNAPSHOT 2) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany:launcher:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), ibiblio (http://www.ibiblio.org/maven2) [INFO] -- -- [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tuscany - DartifactId=hostuti l \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.tuscany:launcher:jar:1.0-SNAPSHOT 2) org.apache.tuscany:hostutil:jar:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.tuscany:launcher:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), ibiblio (http://www.ibiblio.org/maven2) Notice I try this several times but it makes no difference. You need to build hostutil which is in /java first. After
Re: Avoiding extension and application scdl collisions
Please see more comments below. Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 10:27 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote: Hi, It's a bit challenging to run a simple SCA J2SE helloworld sample. Here's the folder structure you have to deal: helloworld --- bin: the launcher.jar, sca-api.jar and host-util.jar --- boot: core.jar, spi.jar, etc --- extension: axis2.jar (optional) helloworld.jar Then you can use the launcher to run helloworld sample. I fully understand the value of isolation for different level of code. I just have a feeling maybe it's too much for a poor J2SE user to get the basic sample working. Ah so this is referring to J2SE client (i.e. from main) and not in a managed environment. I still think this is not that big of a deal. I personally prefer to have directories where I can stick things than a huge classpath. It also avoids the pain of package collisions with application code. Embedded Jetty works like this and I've found it pretty straightforward. I'm not against the isolation which is definitely required for a managed environment. I also agree with you that a huge classpath is not the best pratice even for J2SE. I just wonder if it's still possible for a dummy user to choose one single classpath to include everything. People will also still have to deal with SCDL anyway and that should be in a well-defined location. Having extensions in a well-defined location does not seem to be an additional burden. I'm seeing inconsistency in some places that we still use ClassLoader.getResource() to resolve URLs which seems to me that it violates the idea of isolation by location. For example, we use ClassLoader.getResource(META-INF/tusacny/system.scdl) for the core and ClassLoader.getResource(META-INF/sca/default.scdl) for the application. More importantly, if we are trying to make the use case of a single reference used by a J2SE client easier, I'd would say don't use SCA for that. Just use Axis (or some other transport) directly. Where SCA is valuable is in assembly of multiple services. I'm not sure :-) I think it should also be possible for these guys to take advantage of SCA (I assume SCA can simplify programming). I have some related questions here: 1) Is it possible to use SCA with Tuscany inside a traditional J2SE application with a flat classpath? Can you give a more detailed use case? If it is just accessing one service, or a couple, then my answer would probably be the same as above: use the transport directly, it will always be much easier. If you want to have an application with one SCA service in it wired to others, then a container needs to be deployed and it is not an J2SE application anymore, it is an SCA application running in a J2SE host. I was thinking about adding SCA capability into an existing J2SE app. 2) Where should the dependency jars go? It includes the dependency jars for core runtime and extensions. I'm not sure I follow, what is it? For example, our Axis2 bining has dependencies on Axis2 jars and our core has dependencies on StAX. Where should these jars go? 3) Can I have one extension depend on another extension? Sure, in which case we need to calculate the transitive closure of all dependencies and adjust classpaths accordingly. OSGi will do this for us. I like OSGi too. Why don't we leverage OSGi in the core instead of reinventing the wheels? Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 8:59 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user chooses to do so. Could you explain your reasons why? The only case where I can see this being a good thing for the user is if an extension offers APIs or libraries that must be accessed from the application. In that case, those APIs or libraries should be loaded in a parent to the extension classloader which is then given as a parent to the application classloader (which would be multiparent). Jim To be consistent with the SCA spec (xxx.composite), I suggest that we have the following conventions. core: META-INF/tuscany/system.composite (with includes) extension: META-INF/tuscany/extension.composite application: META-INF/sca/application.composite Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscdev tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 9:26 AM Subject: Avoiding
Re: Avoiding extension and application scdl collisions
It seems changing the default SCDL location names so they are unique does not prevent using classloaders to keep the artifacts from each isolated. Doing this only allows the flexibility that they COULD more easily coexist in the same classloader scope. Given we see the core as something that maybe reused and embedded in many ways, why would we not want to take path that would be more flexible ? So far, I really don't see any disadvantage in changing to this. Raymond Feng wrote: Please see more comments below. Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 10:27 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote: Hi, It's a bit challenging to run a simple SCA J2SE helloworld sample. Here's the folder structure you have to deal: helloworld --- bin: the launcher.jar, sca-api.jar and host-util.jar --- boot: core.jar, spi.jar, etc --- extension: axis2.jar (optional) helloworld.jar Then you can use the launcher to run helloworld sample. I fully understand the value of isolation for different level of code. I just have a feeling maybe it's too much for a poor J2SE user to get the basic sample working. Ah so this is referring to J2SE client (i.e. from main) and not in a managed environment. I still think this is not that big of a deal. I personally prefer to have directories where I can stick things than a huge classpath. It also avoids the pain of package collisions with application code. Embedded Jetty works like this and I've found it pretty straightforward. I'm not against the isolation which is definitely required for a managed environment. I also agree with you that a huge classpath is not the best pratice even for J2SE. I just wonder if it's still possible for a dummy user to choose one single classpath to include everything. People will also still have to deal with SCDL anyway and that should be in a well-defined location. Having extensions in a well-defined location does not seem to be an additional burden. I'm seeing inconsistency in some places that we still use ClassLoader.getResource() to resolve URLs which seems to me that it violates the idea of isolation by location. For example, we use ClassLoader.getResource(META-INF/tusacny/system.scdl) for the core and ClassLoader.getResource(META-INF/sca/default.scdl) for the application. More importantly, if we are trying to make the use case of a single reference used by a J2SE client easier, I'd would say don't use SCA for that. Just use Axis (or some other transport) directly. Where SCA is valuable is in assembly of multiple services. I'm not sure :-) I think it should also be possible for these guys to take advantage of SCA (I assume SCA can simplify programming). I have some related questions here: 1) Is it possible to use SCA with Tuscany inside a traditional J2SE application with a flat classpath? Can you give a more detailed use case? If it is just accessing one service, or a couple, then my answer would probably be the same as above: use the transport directly, it will always be much easier. If you want to have an application with one SCA service in it wired to others, then a container needs to be deployed and it is not an J2SE application anymore, it is an SCA application running in a J2SE host. I was thinking about adding SCA capability into an existing J2SE app. 2) Where should the dependency jars go? It includes the dependency jars for core runtime and extensions. I'm not sure I follow, what is it? For example, our Axis2 bining has dependencies on Axis2 jars and our core has dependencies on StAX. Where should these jars go? 3) Can I have one extension depend on another extension? Sure, in which case we need to calculate the transitive closure of all dependencies and adjust classpaths accordingly. OSGi will do this for us. I like OSGi too. Why don't we leverage OSGi in the core instead of reinventing the wheels? Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 8:59 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user chooses to do so. Could you explain your reasons why? The only case where I can see this being a good thing for the user is if an extension offers APIs or libraries that must be accessed from the application. In that case, those APIs or libraries should be loaded in a parent to the extension classloader which is then given as a parent to the application
Proposed Final Site
I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler
[jira] Created: (TUSCANY-667) New website ready to publish
New website ready to publish Key: TUSCANY-667 URL: http://issues.apache.org/jira/browse/TUSCANY-667 Project: Tuscany Issue Type: New Feature Components: Website Reporter: David Wheeler Attachments: Tuscany Site.zip The new website is ready to go live. There are still a few pages TBD, but all the content that is currently up is included in the new site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-254) Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface
[ http://issues.apache.org/jira/browse/TUSCANY-254?page=all ] Frank Budinsky resolved TUSCANY-254. Resolution: Fixed Fixed in revision 431587. Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface --- Key: TUSCANY-254 URL: http://issues.apache.org/jira/browse/TUSCANY-254 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Environment: All Reporter: Dan Murphy Priority: Minor Fix For: Java-Mx Attachments: Tuscany254.patch The current Java generator generates POJO style java interfaces, if a developer need to use SDO methods then they need to explicitly cast to a DataObject. This wouold be unnecessary and result in better code if the generated classed extended DataObject. This could be acheived by adding a -interfaceDataObject flag to the generator... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
Ok, yes, the recipe is getting more intricate every time, but I got the samples to run now. Thanks. - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 1:45 PM Subject: Re: New build break I'm going to send out a separate mail dealing with how to solve the issues you are seeing long term as I think we are witnessing the results of not having the correct level of modularity in the build. In the meantime, comments below on how to solve this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding extension and application scdl collisions
On Aug 25, 2006, at 10:56 AM, Raymond Feng wrote: Please see more comments below. Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 10:27 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote: Hi, It's a bit challenging to run a simple SCA J2SE helloworld sample. Here's the folder structure you have to deal: helloworld --- bin: the launcher.jar, sca-api.jar and host-util.jar --- boot: core.jar, spi.jar, etc --- extension: axis2.jar (optional) helloworld.jar Then you can use the launcher to run helloworld sample. I fully understand the value of isolation for different level of code. I just have a feeling maybe it's too much for a poor J2SE user to get the basic sample working. Ah so this is referring to J2SE client (i.e. from main) and not in a managed environment. I still think this is not that big of a deal. I personally prefer to have directories where I can stick things than a huge classpath. It also avoids the pain of package collisions with application code. Embedded Jetty works like this and I've found it pretty straightforward. I'm not against the isolation which is definitely required for a managed environment. I also agree with you that a huge classpath is not the best pratice even for J2SE. I just wonder if it's still possible for a dummy user to choose one single classpath to include everything. I think we should help the dummy user get their setup correct. People will also still have to deal with SCDL anyway and that should be in a well-defined location. Having extensions in a well- defined location does not seem to be an additional burden. I'm seeing inconsistency in some places that we still use ClassLoader.getResource() to resolve URLs which seems to me that it violates the idea of isolation by location. For example, we use ClassLoader.getResource(META-INF/tusacny/system.scdl) for the core and ClassLoader.getResource(META-INF/sca/default.scdl) for the application. We should fix that inconsistency. More importantly, if we are trying to make the use case of a single reference used by a J2SE client easier, I'd would say don't use SCA for that. Just use Axis (or some other transport) directly. Where SCA is valuable is in assembly of multiple services. I'm not sure :-) I think it should also be possible for these guys to take advantage of SCA (I assume SCA can simplify programming). SCA doesn't simplify all programming. Sometimes it's just easier to avoid the unnecessary overhead of frameworks. I have some related questions here: 1) Is it possible to use SCA with Tuscany inside a traditional J2SE application with a flat classpath? Can you give a more detailed use case? If it is just accessing one service, or a couple, then my answer would probably be the same as above: use the transport directly, it will always be much easier. If you want to have an application with one SCA service in it wired to others, then a container needs to be deployed and it is not an J2SE application anymore, it is an SCA application running in a J2SE host. I was thinking about adding SCA capability into an existing J2SE app. For me, the use case here would be wiring to or from a service in an existing app. This is one of the main uses cases for Spring (and EJB, etc.). The way I would do this is not through a J2SE client but by including the application in a composite and using composite services or references to wire to and from children in the application. 2) Where should the dependency jars go? It includes the dependency jars for core runtime and extensions. I'm not sure I follow, what is it? For example, our Axis2 bining has dependencies on Axis2 jars and our core has dependencies on StAX. Where should these jars go? It depends. Generally, I would isolate the StAX dependency between extensions since they may depend on a different version. 3) Can I have one extension depend on another extension? Sure, in which case we need to calculate the transitive closure of all dependencies and adjust classpaths accordingly. OSGi will do this for us. I like OSGi too. Why don't we leverage OSGi in the core instead of reinventing the wheels? I agree with you here if OSGi gives us what we need (and hopefully it does). Thanks, Raymond - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 8:59 AM Subject: Re: Avoiding extension and application scdl collisions On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote: Hi, I understand we endeavor to support isolated classloading for system, extension, and application. But I think we should be able to run a SCA application with the runtime and extension jars on its classpath if the user
Re: svn properties...
Dan, I disabled the test that was failing. It's a new SDO test, that seems to work in some time zones and fail in others. Sorry about that, and thanks for doing this. Frank. Daniel Kulp [EMAIL PROTECTED] wrote on 08/25/2006 12:26:34 PM: Actually, I'm seeing a build failure in SDO (test failure), although it's doing that in a clean view as well.I don't have time to investigate that right now. Thus, I'm going to wait till monday to do this. I don't want to make some big changes when I know there is a failure. Dan On Friday August 25 2006 12:07 pm, Daniel Kulp wrote: OK. I'm going to go ahead and do this. It seems to look pretty good and doesn't break any tests. The main problem seems to be the SDO section with a lot of files without the proper eol-style property which causes some big cleanups. Dan On Friday August 25 2006 9:35 am, Daniel Kulp wrote: To help out Yoko, I wrote a quick script that will properly set the svn properties on all the files in their repository. I've attached it. Would there be any objection to me running it on all of tuscany/trunk? (including sdo, spec, das?) I've noticed there are a LOT of files that don't have the properties set, or if they are set, they are set wrong. Example: svn:keywords should be set as Rev Date, not Rev,Date. (space delimited) It would be a wrather large commit, but doesn't change any code other than to fix cr/lf issues if eol-style wasn't set and possibly fill in the correct Rev and Date things. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 F:781-902-8001 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
Hello Jim, I attempted this on a variety of time/timezone environments and thought I had addressed all the possibilities in terms of TimeZones, daylight savings time, northern and southern hemispheres, etc. Can you tell me what TimeZone you are in and about what time you ran the test with failure? On 8/25/06, Jim Marino [EMAIL PROTECTED] wrote: I just synced SDO and am getting the following when building from /java: junit.framework.AssertionFailedError: The expected value did not result when calling toDay after initializing with toDay. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.executeConversion(DateConversionTestCase.java:167) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.attemptConversion(DateConversionTestCase.java:148) at org.apache.tuscany.sdo.test.DateConversionTestCase.testConversionsFromDa y(DateConversionTestCase.java:200) I would be surprised if this is from any of the changes to SCA. Jim On Aug 25, 2006, at 9:08 AM, Jim Marino wrote: Hi Ignacio, The build runs fine for me. Did you try mvn clean first? Can you send a stacktrace if it persists? Jim On Aug 25, 2006, at 7:00 AM, Ignacio Silva-Lepe wrote: The latest update, that updates a lot of the core/implementation/ processors, seems to be breaking a lot if not all of the sca samples. The way I see this is by doing a mvn clean and mvn -e from the top, which breaks while running the tests for the SDO impl, so then I go to sca/core and do mvn -e and then go to samples/sca and do mvn -e. This is where I see various exceptions from processors such as ServiceProcessor and HeuristicPojoProcessor, including NPE, from samples that used to run, such as supply chain and samplecallback. Any ideas? - 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: Proposed Final Site
David, Thank you for your effort on this. Site prototype is much more user friendly and easier to follow. I looked through the readme. It is not clear to me how to deploy/build the site changes. Can you please add those steps to the read me? We used to have a link on the website that explained how to modify the website. It would be good to have that information under development box. What are the .svg files? Haleh On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler
Re: Proposed Final Site
You don't build the website Simple changing the XML files changes the website. Deploying the website is simply putting all the files in the site folder into the root of the site on incubator.apache.org/tuscany I will try and clarify that in the readme. as well as post it under the development section. .svg files are Scalable Vector Graphics files ( http://www.w3.org/Graphics/SVG/). Inkscape uses svg as its native file format. -David On 8/25/06, haleh mahbod [EMAIL PROTECTED] wrote: David, Thank you for your effort on this. Site prototype is much more user friendly and easier to follow. I looked through the readme. It is not clear to me how to deploy/build the site changes. Can you please add those steps to the read me? We used to have a link on the website that explained how to modify the website. It would be good to have that information under development box. What are the .svg files? Haleh On 8/25/06, David Wheeler [EMAIL PROTECTED] wrote: I think the new site is ready to go live. There are still a few pages tbd, but all the content that is on the current site is in the new one. I have created a JIRA issue with the site source attached. http://issues.apache.org/jira/browse/TUSCANY-667 The Zip also contains a readme with instuctions on how to modify the site and craete new pages. -David Wheeler
Re: DataObject/DataGraph Serialization DataGraphRoot
It may be that your remote client has not initialized the SDO/EMF
environment properly and I think that we need some help from the SDO
team. I have copied this to the dev list since not everyone has
registered yet for the user list.
--Kevin
Luciano Resende wrote:
Hi Scott
So, here is a quick example from our unit testings :
/**
* Read a specific customer
*/
public void testReadSingle() throws Exception {
//Create and initialize command to read customers
DAS das = DAS.FACTORY.createDAS(getConnection());
Command readCustomers = das.createCommand(select * from
CUSTOMER where ID = 1);
//Read
DataObject root = readCustomers.executeQuery();
//Verify
assertEquals(1, root.getInt(CUSTOMER[1]/ID));
}
If you get a reference to root first, then try to access the customer
information, do you still have this problem ?
Maybe something like this :
DataObject root = readCust.executeQuery();
cust = root.getDataObject(CUSTOMER)
Please let me know if this helps...
- Luciano
On 8/24/06, *Scott Kurinskas* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
Now that my DAS example is up and running, I'm trying to move my
example to
a client/server environment and integrate it with my product. My
use-case
is very simple, a client makes a request to the server, the server
fetches
the result from the database and returns the DataObject back to
the client.
The server side code looks like the following:
das = DAS.FACTORY.createDAS(getConfig(CompanyConfig.xml),
connection);
String sql = Select * from customers where
customers.customerNumber = +
key;
Command readCust = das.createCommand(sql);
DataObject cust = readCust.executeQuery();
return cust;
The code executes fine on the client but for some reason the
client is
throwing the exception below. The client should be deserializing the
response into a DataObject, but for some reason its complaining
about class
DataGraphRoot not found. The same code executing in a app works
great.
Thoughts?
Thanks again,
Scott
Caught unexpected Exception
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class
'DataGraphRoot' not found.
( file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20%20Cache%20
file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20%20Cache%20
Client/all.datagraph %20Cache%20Client/all.datagraph, 5, 22)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:80)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java :189)
at
org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceIm
pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java
:1
79)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1089
)
at
org.apache.tuscany.sdo.impl.DataGraphImpl$EDataGraphExternalizable.readExter
nal(DataGraphImpl.java:665)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1758)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1716)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java :1304)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readDataObje
ct(HelperProviderImpl.java:205)
at
org.apache.tuscany.sdo.helper.HelperProviderImpl$ResolvableImpl.readExternal
(HelperProviderImpl.java:144)
at
commonj.sdo.impl.ExternalizableDelegator.readExternal(ExternalizableDelegato
r.java:80)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1758)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1716)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at
com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3200)
at
com.gemstone.gemfire.internal.util.BlobHelper.deserializeBlob(BlobHelper.jav
a:55
--
-
Luciano Resende
SOA Opensource - Apache Tuscany
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DataObject/DataGraph Serialization DataGraphRoot
Hi Yang,
Comments in line ...
Yang ZHONG wrote:
You may need to serialize the generated SDO metadata. On the other
hand, I
recommend the scenario design to be reconsidered.
Thank Frank for suggesting a SDOUtil helper taking a list of Types for
DAS
to serialize all generated Types along with DataGraph.
If you're willing to do that, I'll implement and send it out.
Yes. Please implement this method. If I understand correctly, the
function exists today in EMF but we prefer to stay with SDO apis. Also,
I am not sure why the method should take a list of generated Types since
they exist in the graph already. So, why not a method something like
this: serializeTypes() ?
At the same time, I have some thoughts on the scenario design. DataBase
schema is unlikely changed frequently, it's inefficient for DAS to always
generate same SDO metadata over and over again on every single query,
it's
also inefficient to serialize same SDO metadata over and over again on
every
single invocation back to client. A typical customer scenario is, both
client and server have SDO metadata already, therefore SDO metadata
serialization isn't really necessary, and SDO metadata generation from
DAS
isn't really necessary. I know an early version of DAS (it was under
different name) can accept existing SDO metadata and generate only SDO
instances. My previous product customers actually complained about the
very
poor performance caused by repeating same SDO metadata generation and
serialization.
So, are you interested in trying such scenario so that you won't have
type
not found problem?
Solution 2-1 (typical real scenario):
1. deploy SDO metadata to both client and server
2. instruct DAS to accept the existing SDO metadata
3. do rest of whatever being done right now
The DAS supports this scenario today and can accept Static Types from
the client. But, the purely dynamic scenario is an important one so we
must support both.
Thanks!
Solution 2-2 (temporary if current DAS doesn't take any SDO metadata yet)
1. deploy the generated SDO metadata from DAS to client, once
2. do rest of whatever being done right now
On 8/25/06, Kevin Williams [EMAIL PROTECTED] wrote:
The RDB DAS creates the graph and corresponding Types dynamically from
the database query results.
Frank Budinsky wrote:
The problem seems to be that the metadata for class DataGraphRoot is
not
registered on the client. Is that the only missing metadata? What about
the metadata for the rest of the model. I can't provide any more help
without more details about how the metadata is being defined.
Frank.
Kevin Williams [EMAIL PROTECTED] wrote on 08/25/2006 03:30:15 PM:
It may be that your remote client has not initialized the SDO/EMF
environment properly and I think that we need some help from the SDO
team. I have copied this to the dev list since not everyone has
registered yet for the user list.
--Kevin
Luciano Resende wrote:
Hi Scott
So, here is a quick example from our unit testings :
/**
* Read a specific customer
*/
public void testReadSingle() throws Exception {
//Create and initialize command to read customers
DAS das = DAS.FACTORY.createDAS(getConnection());
Command readCustomers = das.createCommand(select * from
CUSTOMER where ID = 1);
//Read
DataObject root = readCustomers.executeQuery();
//Verify
assertEquals(1, root.getInt(CUSTOMER[1]/ID));
}
If you get a reference to root first, then try to access the customer
information, do you still have this problem ?
Maybe something like this :
DataObject root = readCust.executeQuery();
cust = root.getDataObject(CUSTOMER)
Please let me know if this helps...
- Luciano
On 8/24/06, *Scott Kurinskas* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi,
Now that my DAS example is up and running, I'm trying to move my
example to
a client/server environment and integrate it with my product. My
use-case
is very simple, a client makes a request to the server, the
server
fetches
the result from the database and returns the DataObject back to
the client.
The server side code looks like the following:
das = DAS.FACTORY.createDAS(getConfig(CompanyConfig.xml),
connection);
String sql = Select * from customers where
customers.customerNumber = +
key;
Command readCust = das.createCommand(sql);
DataObject cust = readCust.executeQuery();
return cust;
The code executes fine on the client but for some reason the
client is
throwing the exception below. The client should be deserializing
the
response into a DataObject, but for some reason its complaining
about class
DataGraphRoot not found. The same code executing in a app works
great.
Thoughts?
Thanks again,
Scott
Caught unexpected Exception
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class
Re: New build break
Hi Brian, I ran this about 9PST and again at 4.53PST and received: testConversionsFromDay (org.apache.tuscany.sdo.test.DateConversionTestCase) Time elapsed: 0.01 sec FAILURE! [ stacktrace ] --- junit.framework.AssertionFailedError: The expected value did not result when calling toDay after initializing with toDay. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.executeConversion(DateConversionTestCase.java:167) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.attemptConversion(DateConversionTestCase.java:148) at org.apache.tuscany.sdo.test.DateConversionTestCase.testConversionsFromDa y(DateConversionTestCase.java:200) 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:154) at junit.framework.TestCase.runBare(TestCase.java:127) I'm on OS X and JDK: java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112) Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing) This isn't blocking anything I'm working on but I'm happy to help diagnose the problem. Jim On Aug 25, 2006, at 11:55 AM, Brian Murray wrote: Hello Jim, I attempted this on a variety of time/timezone environments and thought I had addressed all the possibilities in terms of TimeZones, daylight savings time, northern and southern hemispheres, etc. Can you tell me what TimeZone you are in and about what time you ran the test with failure? On 8/25/06, Jim Marino [EMAIL PROTECTED] wrote: I just synced SDO and am getting the following when building from / java: junit.framework.AssertionFailedError: The expected value did not result when calling toDay after initializing with toDay. at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.executeConversion(DateConversionTestCase.java:167) at org.apache.tuscany.sdo.test.DateConversionTestCase $Test.attemptConversion(DateConversionTestCase.java:148) at org.apache.tuscany.sdo.test.DateConversionTestCase.testConversionsFro mDa y(DateConversionTestCase.java:200) I would be surprised if this is from any of the changes to SCA. Jim On Aug 25, 2006, at 9:08 AM, Jim Marino wrote: Hi Ignacio, The build runs fine for me. Did you try mvn clean first? Can you send a stacktrace if it persists? Jim On Aug 25, 2006, at 7:00 AM, Ignacio Silva-Lepe wrote: The latest update, that updates a lot of the core/implementation/ processors, seems to be breaking a lot if not all of the sca samples. The way I see this is by doing a mvn clean and mvn -e from the top, which breaks while running the tests for the SDO impl, so then I go to sca/core and do mvn -e and then go to samples/sca and do mvn -e. This is where I see various exceptions from processors such as ServiceProcessor and HeuristicPojoProcessor, including NPE, from samples that used to run, such as supply chain and samplecallback. Any ideas? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build breaks (and how to fix them)
Many of us have experienced build breaks over the past several weeks, particularly in the Java SCA project. I believe the root of the problem to be not having the correct level of modularity. I would like to start with a general approach on how to fix this and once we gain consensus, move to creating a proposal for changing the current build structure. 1. The source tree should be independently built from individual projects under /java, sca, sdo, and das. Currently it is not since buildtools is required. I would like to get to the point where people can check out individual sub projects only and build from there. 2. For SCA Java, as Ant proposed, the samples dealing with extensions would move to their appropriate extension projects. Samples that used multiple extensions (e.g. BigBank with Celtix and Axis) would stay under samples/sca 3. API, SPI, core, hostutil, host-api would be built independently under a subdirectory of /sca 4. Runtime host projects would be build independently under a subdirectory of /sca 5. Extensions would move into into a subdirectory of /sca (they could still be organized according to type) and be built individually against a particular version of the core jars. This would mean that extensions are not built together and are not built with the core. This would shield the entire build process from breaking when an extension breaks (e.g. Axis and Axiom not being in sync). It would also mean changes to the core could be vetted and not impact work being done on extensions. Thoughts? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New build break
On Aug 25, 2006, at 11:35 AM, Ignacio Silva-Lepe wrote: Ok, yes, the recipe is getting more intricate every time, but I got the samples to run now. Thanks. Yea unfortunately it is. I've just launched a new thread on how to fix this by introducing more modularity. Sorry for all the issues. - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 25, 2006 1:45 PM Subject: Re: New build break I'm going to send out a separate mail dealing with how to solve the issues you are seeing long term as I think we are witnessing the results of not having the correct level of modularity in the build. In the meantime, comments below on how to solve this. - 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]
