Re: [C++] Coding convention for #ifndef in our includes
I prefer the SCA style rather than the ones in SDO. The full path is better
as well so
#ifndef commonj_sdo_changeddataobjectlist_h
is what I would use.
However, I don't think this affects the readabillity of the code so I don't
propose we change them all. We need to update the licence header in every
file at some point so we could change these at that time if necessary.
Cheers,
PS. Let's not get into the discussion on where you place your opening {.
If the code is readable then it's ok by me rather than getting anal on code
formating standards ;-)
On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I see two different coding conventions for the usual
#ifndef/#define/#endif in our include files:
#ifndef tuscany_sca_model_binding_h in tuscany::sca::model::Binding.h
#ifndef _CHANGEDDATAOBJECTLIST_H_ in commonj::sdo::ChangedDataObjectList.h
Can we decide on a common convention? I have used both conventions in
the past, so I'm OK with either but think it'd be nicer if we could pick
one and stick to it.
Until we make a decision I'll follow my old code maintainer habit to
stick to the scheme I see in the code around what I'm adding/changing.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Pete
[jira] Resolved: (TUSCANY-661) Make celtix biding working for helloworldwsclient and helloworldws-celtix
[ http://issues.apache.org/jira/browse/TUSCANY-661?page=all ] Jim Marino resolved TUSCANY-661. Resolution: Fixed applied Make celtix biding working for helloworldwsclient and helloworldws-celtix - Key: TUSCANY-661 URL: http://issues.apache.org/jira/browse/TUSCANY-661 Project: Tuscany Issue Type: Improvement Affects Versions: Java-Mx Reporter: Jervis Liu Attachments: jira661.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-662) Axis2 Binding's OperationClient needs to be reset to support repeated invocation
Axis2 Binding's OperationClient needs to be reset to support repeated invocation Key: TUSCANY-662 URL: http://issues.apache.org/jira/browse/TUSCANY-662 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Environment: Revision: 433239 Reporter: Scott Kurz When I invoke my service w/ WS binding (Axis2) a second time I get the following exception stack trace: java.lang.reflect.InvocationTargetException at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:138) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(Axis2TargetInvoker.java:145) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.jdk.AbstractJDKOutboundInvocationHandler.invoke(AbstractJDKOutboundInvocationHandler.java:75) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:83) ... 32 more Caused by: org.apache.axis2.AxisFault: Invalid message addition , operation context completed at org.apache.axis2.description.OutInAxisOperation.addMessageContext(OutInAxisOperation.java:64) at org.apache.axis2.context.OperationContext.addMessageContext(OperationContext.java:89) at org.apache.axis2.description.AxisOperation.registerOperationContext(AxisOperation.java:369) at org.apache.axis2.description.OutInAxisOperationClient.addMessageContext(OutInAxisOperation.java:158) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:99) In looking at the source for method addMessageContext in class org.apache.axis2.description.OutInAxisOperation it appears that the operation context needs to be reset or cleared somehow so that both the in and out values are not set during subsequent invocations after the first. -- 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-662) Axis2 Binding's OperationClient needs to be reset to support repeated invocation
[ http://issues.apache.org/jira/browse/TUSCANY-662?page=all ] Raymond Feng resolved TUSCANY-662. -- Resolution: Fixed Assignee: Raymond Feng Fixed by SVN revision 434263. Axis2 Binding's OperationClient needs to be reset to support repeated invocation Key: TUSCANY-662 URL: http://issues.apache.org/jira/browse/TUSCANY-662 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Environment: Revision: 433239 Reporter: Scott Kurz Assigned To: Raymond Feng When I invoke my service w/ WS binding (Axis2) a second time I get the following exception stack trace: java.lang.reflect.InvocationTargetException at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:138) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(Axis2TargetInvoker.java:145) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.jdk.AbstractJDKOutboundInvocationHandler.invoke(AbstractJDKOutboundInvocationHandler.java:75) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:83) ... 32 more Caused by: org.apache.axis2.AxisFault: Invalid message addition , operation context completed at org.apache.axis2.description.OutInAxisOperation.addMessageContext(OutInAxisOperation.java:64) at org.apache.axis2.context.OperationContext.addMessageContext(OperationContext.java:89) at org.apache.axis2.description.AxisOperation.registerOperationContext(AxisOperation.java:369) at org.apache.axis2.description.OutInAxisOperationClient.addMessageContext(OutInAxisOperation.java:158) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:99) In looking at the source for method addMessageContext in class org.apache.axis2.description.OutInAxisOperation it appears that the operation context needs to be reset or cleared somehow so that both the in and out values are not set during subsequent invocations after the first. -- 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: Text for main page of Tuscany website
Could the General Tuscany diagram would go here be moved from being right at the bottom to nearer the top so you see it all without having to scroll the page down? ...ant On 8/24/06, haleh mahbod [EMAIL PROTECTED] wrote: Hello Tuscany community, Please review the following text as a proposed text for our main web page. Jim, Thanks for your feedback. I tried to capture your comments in the new writeup. Please feel free to re-write this if you think it needs improvement :) Haleh --- Start of text --- Welcome to the Apache Tuscany free open source project that is licensed under version 2 of the Apache Licensehttp://www.apache.org/licenses/LICENSE-2.0_. This project is currently in incubation within the Apache incubator. The aim of the Apache Tuscany project is to create, as a community, a robust infrastructure that simplifies the development of SOA-based systems. Apache Tuscany is based on independent technologies that together provide one complete infrastructure which caters to this goal. This includes the following: · Service Component Architecture (SCA) enables composition of service networks through assembly of existing and new services. Apache Tuscany implements SCA in Java and C++. Tuscany SCA runtime can easily be extended to support any communication transport, qualities of service or programming model and can be used in conjunction with other technologies such as Spring, Axis and Celtix. · Service Data Object (SDO) provides a uniform interface for handling different forms of data that can exist in a network of services and provides the mechanism for tracking changes in data. Apache Tuscany provides Java and C++ implementations for SDO. · Service Data Access (DAS) provides a uniform interface for interacting with persistent data when using SDO. Apache Tuscany provides a Java implementation for DAS. SCA and SDO technologies can be used independent of one another. The specifications for these technologies are located at www.osoa.org. Apache Tuscany project provides input to the specifications. Please join us to develop this innovative infrastructure and/or provide feedback based on real use case scenarios which will help Apache Tuscany become a first class solution for simplifying the development of SOA-based systems. General Tuscany diagram would go here On 8/17/06, Jim Marino [EMAIL PROTECTED] wrote: Thanks Haleh for taking the time to write this up again...more comments inline. Jim On Aug 16, 2006, at 6:34 PM, haleh mahbod wrote: Jim, Thanks for the comments. I took a look at the links and your comments. How about this write-up? Welcome to the Apache Tuscany free open source project that is licensed under version 2 of the Apache Licensehttp://www.apache.org/licenses/LICENSE-2.0_. This project is currently in incubation within the Apache incubator. The aim of the Apache Tuscany is to create, as a community, a robust framework that simplifies the development of SOA-based systems through seamless handling of many infrastructure and data handling complexities which exist in heterogeneous Service Oriented Architecture (SOA) environment. IMO the first statement needs to be really direct and as free of buzzwords as possible since it is the first thing people are going to judge us on. I'd try and limit the use of SOA as much as possible since the term is abused these days. I'd also try and not talk about business problems since we are targeting primarily systems developers (to join the project) and secondarily end-user applications developers. With that in mind, I would say Tuscany is infrastructure (as opposed to a framework like Rails, RIFE, parts of Spring, etc.) that simplifies the development of SOA-based systems. It does so by providing technology for composing service networks (service assemblies) based on SCA and technologies for managing data in that environment based on SDO. At some point I also think we need to make it clear that SCA, SDO and DAS are independent technologies. If I had to characterize the message I would want to send the two constituencies it would be: - system developers: the stuff we're working on involves solving really hard problems and you should be part of building out the next generation infrastructure and doing innovative things. - application developers: our technologies are cool, work with stuff you already know, and will enable you to build really interesting applications. Tuscany reduces development effort and cost by enabling the application developer to focus on addressing the business problem. Tuscanyconsists of the following technologies: · Tuscany runtime is based on Service Component Architecture (SCA) specification and provides the infrastructure for hosting and assembling services. This
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
different databinding technologies on the same interface are you, and
would
a lot of this have defaults so you don't have to specify all this for
every
operation?
...ant
On 8/21/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I'm trying to define the XML schema for the tuscany databinding
extension
to describe the data types for input and output. Here's an example.
Please
note databinding will be an extension to the interface type.
interface.java interface=sample.CreditReportService
tuscany:databinding xmlns:tuscany=
http://tuscany.apache.org/xmlns/1.0-SNAPSHOT
operation name=getCreditReport
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.java
Any opinions?
Thanks,
Raymond
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Interceptors to convert objects to XmlObjects for JavaScript/E4X support
Hi Ant,
I have been able to do the injection of required JS XmlObjects into the
script. The service invocation works fine.
I am now looking at the references part and am bit stuck there. There is a
problem in converting the javascript xml objects to the Java counterparts
(something that is being done in the RhinoInvoker for services side).
How are references injected into the javascript? Right now I understand
that, using the reference name as mentioned in the componentType file I am
able to access this object. But how did it get inject in the first place?
Please help with some info or pointers. Thanks.
- Venkat
On 8/23/06, ant elder [EMAIL PROTECTED] wrote:
I've had some offline chats with Venkat about this. I'd not ported any of
the E4X code over from M1 so Venkat is looking at that. The XML instance
utility being talked about is for JIRA TUSCANY-419. Here's a bit more
detail
on TUSCANY-419 and how it would work.
Today an E4X helloworld function looks like this:
function getGreeting(xmlIn) {
var greeting = e4xHello + xmlIn..*::in0;
var xmlOut =
helloworld:getGreetingsResponse xmlns:helloworld=
http://integration.rhino.container.tuscany.apache.org;
helloworld:getGreetingsReturn { greeting }
/helloworld:getGreetingsReturn
/helloworld:getGreetingsResponse;
return xmlOut;
}
There's a lot of boilerplate XML in there which could be determined
automatically from the WSDL, so ideally the function could rewritten
something like:
function getGreeting(xmlIn) {
var xmlOut = _getXML(getGreetingResponse);
xmlOut.getGreetingsReturn = e4xHello + xmlIn..*::in0;
return xmlOut;
}
The _getResponseXML function is a system supplied function that the
JavaScript container injects into the script environment. It returns an
E4X
XML object that is an representation of the WSDL schema with all the
values
defaulting. Thats worked out based on the interface of the component,
there
could be similar ones for references, eg, if there is a reference named
foo
you could do foo._getXML(fooType).
...ant
On 8/20/06, Venkata Krishnan [EMAIL PROTECTED] wrote:
Hi Ant,
Is this something that works in M2 now? I remember doing a util for
creating xml instances for this.
When I see the current trunk's javascript container I don't see the e4x
samples. Shall I try moving them over and intergrating with the xml
instance creation utility. Please let me know.
Thanks.
- Venkat
On 6/7/06, ant elder [EMAIL PROTECTED] wrote:
No reply to this yet...after a little playing around it seems to work
so
I'm
going to go ahead unless anyone raises any objections now. Sebastien,
you
did the async work using PolicyBuilders and Interceptors so have you
any
comments to what I suggested in the email below?
...ant
On 6/6/06, ant elder [EMAIL PROTECTED] wrote:
I wondered about using Tuscany PolicyBuilders and Interceptors to
help
with E4X support for the work required in TUSCANY-418, TUSCANY-419,
and
TUSCANY-420. Right now the E4X code isn't so elegant with the way it
works
out when and how to convert the Java objects in a message into E4X
XML,
and
with the current code i can't get E4X XML as parameters on reference
invocations working.
Looking at how the code for async works, it seems like for E4X
support
there could be source and target policy builders that look at the
wires
and
when required (*) insert an interceptor that converts the message
objects
from/to XmlObjects, and then the JavaScript container would simply
always
convert XmlObjects from/to E4X XML objects.
(*) the when required would be something like when the wire target
is
a
JavaScript component with interface described by a WSDL portType, or
a
wire
source is a JavaScript component and the wire target has an
interface
described with WSDL.
Does this sound like a reasonable use of PolicyBuilders and
Interceptors?
It seems like something like this may also be a step on the way to
the
efficient streaming of messages in TUSCANY-104?
...ant
Re: REST bindings for Tuscany SCA runtime
Ok, my I tried to send this email earlier, but it bounced as spam, so I'm going to try again with a link to my attachment and see if that helps So I'm sure it is something stupid, but I'm missing something. I've got the sample webapp packaged correctly (I think) and it was giving the error about the unrecognized element binding.jasonrpc. I then added my jsonrpc-1.0-SNAPSHOT.jar that I thought was at least mocked up correctly to get me onto the next error, but it doesn't seem to be getting picked up, and I still have the unrecognized element binding.jsonrpc error. Here is a link to a zip of my binding.jsonrpc source tree. Any ideas? http://bertlamb.com/binding.jsonrpc.zip Thanks! -Bert On 8/18/06, ant elder [EMAIL PROTECTED] wrote: Hi Bert, I agree there's going to be some challenges to solve to integrate REST well with Tuscany, I'll stay out of that for now and focus on how to get you started with bindings. Implementing a simple binding would be a good place to start so if you want to port over the old jsonrpc binding that would be great. The code for that is at, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/, and there's a sample, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/. You could download the Tuscany M1 distribution if you want to see the sample running. I'd start by taking the sample and getting it to fit in with the new code base - convert the SCDL to the new format, and get the war packaging correct. You could use the Axis2 WS sample as a model for that which is at, http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/. (The WAR packaging is going to change once I finish the TuscanyServletListener and ServletHost work, I'll let you know when that goes in) Once you get the WAR right when you deploy it to tomcat you should see an exception about an unrecognized element: binding.jsonrpc, thats because Tuscany doesn't have a binding for it so now you need to convert the binding over to the new Tuscany runtime. There's several bindings to use as models, the RMI or echo ones are simple, the Axis2 uses the ServletHost which you'll also need to do: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc only supports services. There's also a binding using DWR instead of json-rpc-java which you port to the new runtime and its a bit more interesting as it also supports references (well, externalServices) so you could look at that as well if you're interested: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. If you search back in the dev list archives there's a few mails where we talk about what these two binding do. Hope this helps, ...ant On 8/17/06, Bert Lamb [EMAIL PROTECTED] wrote: On 8/16/06, Jeremy Boynes [EMAIL PROTECTED] wrote: In terms of the basic transport, in M1 we had a JSON-RPC binding that supported JSON encoded data over HTTP. We have not got around yet to porting that to the new structure in the trunk. Looking at that would be a good way to dig into how Tuscany works. I can make an attempt to try and port the jsonrpc binding from M1 over to trunk style extensions if this would be appreciated. I agree that should help me get an understanding of how some of Tuscany works. Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? Yes, the more I read, the more I wonder if trying to support REST style web applications in SCA is going to become a square peg in a round hole problem. I've only begun really looking at this though, and welcome any thoughts on the subject of how one might attempt to interface REST resources in SCA. -Bert - 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: REST bindings for Tuscany SCA runtime
It looks pretty good. I'm guessing the system scdl being used by the web app doesn't include the scdl for your binding. The way the sample webapps are done right now with all the jars going into the webapp lib you need to add all extensions to the system scdl being used. In you web.xml there's a parameter systemScdlPath which is set to /META-INF/sca/webapp.system.scdl. That will pick up the resource from the webapp-host.jar. Update that file or copy it somewhere else and update the systemScdlPath to point at the new file, and add in your jsonrpc scdl elements. Once we get extension plugabilty going properly in the samples this wont be necessary. ...ant On 8/24/06, Bert Lamb [EMAIL PROTECTED] wrote: Ok, my I tried to send this email earlier, but it bounced as spam, so I'm going to try again with a link to my attachment and see if that helps So I'm sure it is something stupid, but I'm missing something. I've got the sample webapp packaged correctly (I think) and it was giving the error about the unrecognized element binding.jasonrpc. I then added my jsonrpc-1.0-SNAPSHOT.jar that I thought was at least mocked up correctly to get me onto the next error, but it doesn't seem to be getting picked up, and I still have the unrecognized element binding.jsonrpc error. Here is a link to a zip of my binding.jsonrpc source tree. Any ideas? http://bertlamb.com/binding.jsonrpc.zip Thanks! -Bert On 8/18/06, ant elder [EMAIL PROTECTED] wrote: Hi Bert, I agree there's going to be some challenges to solve to integrate REST well with Tuscany, I'll stay out of that for now and focus on how to get you started with bindings. Implementing a simple binding would be a good place to start so if you want to port over the old jsonrpc binding that would be great. The code for that is at, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/ , and there's a sample, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/ . You could download the Tuscany M1 distribution if you want to see the sample running. I'd start by taking the sample and getting it to fit in with the new code base - convert the SCDL to the new format, and get the war packaging correct. You could use the Axis2 WS sample as a model for that which is at, http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/ . (The WAR packaging is going to change once I finish the TuscanyServletListener and ServletHost work, I'll let you know when that goes in) Once you get the WAR right when you deploy it to tomcat you should see an exception about an unrecognized element: binding.jsonrpc, thats because Tuscany doesn't have a binding for it so now you need to convert the binding over to the new Tuscany runtime. There's several bindings to use as models, the RMI or echo ones are simple, the Axis2 uses the ServletHost which you'll also need to do: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc only supports services. There's also a binding using DWR instead of json-rpc-java which you port to the new runtime and its a bit more interesting as it also supports references (well, externalServices) so you could look at that as well if you're interested: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. If you search back in the dev list archives there's a few mails where we talk about what these two binding do. Hope this helps, ...ant On 8/17/06, Bert Lamb [EMAIL PROTECTED] wrote: On 8/16/06, Jeremy Boynes [EMAIL PROTECTED] wrote: In terms of the basic transport, in M1 we had a JSON-RPC binding that supported JSON encoded data over HTTP. We have not got around yet to porting that to the new structure in the trunk. Looking at that would be a good way to dig into how Tuscany works. I can make an attempt to try and port the jsonrpc binding from M1 over to trunk style extensions if this would be appreciated. I agree that should help me get an understanding of how some of Tuscany works. Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? Yes, the more I read, the more I wonder if trying to support REST style web applications in SCA is going to become a square peg in a
Re: [jira] Created: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
Hi, I was able to resolve the issues and run all the test cases. I have attached a zip file to the JIRA, which you can find at: https://issues.apache.org/jira/secure/attachment/12339477/tuscany-sca-tools.zip In the M1 version, there was a dependancy on tuscany\sca\model\src\main\java\org\apache\tuscany\model\util\XMLNameUtil. This is not available in the current release. So I have re-packeged this file into the tools package. On 8/23/06, Jojo [EMAIL PROTECTED] wrote: Hi Ant, Thanks for looking into this. Unfortuately I had a machine crash sometime back and trying to recover. So I won't be able to give you a patch. And the code is not yet in SVN. I am trying to run it usig Maven. I will try to give you a zip file with the code. Thanks and regards, jojo. On 8/23/06, ant elder [EMAIL PROTECTED] wrote: Jojo, it should be picking up the Woodstox jar (eg, wstx-asl-2.9.3.jar), this error is saying it can't find that jar. Is that jar in your classpath? Could you describe a bit more how you're try to run this - in eclipse or mvn, is the code in SVN so I can try? ...ant On 8/22/06, Jojo [EMAIL PROTECTED] wrote: Hi, I was trying to get some java2wsdl test case running, but got stuck with the following error : javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance( XMLInputFactory.java:136) I remember seeing this problem previously discussed in the thread [Axiom and classloaders, was: svn commit: r429905] and was fixed subsequently. But the fix was not discussed in the tread. I understand this is a classloader/classpath issue. Can someone tell me what was the fix ? The same fix need to be applied to the sca-tools project. Thanks! jojo. On 8/22/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Rick, I can with this. Please let me know what else needs to be done to the existing code in M1 in the context of M2 after you have moved the code over to the current trunk. Thanks - Venkat On 8/22/06, Rick Rineholt (JIRA) tuscany-dev@ws.apache.org wrote: Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- 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] -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Warm regards, jojo. -- Warm regards, jojo. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with porting jsonrpc binding
Ant, Changed the subject which I forgot to do on the last email... 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? -Bert On 8/24/06, ant elder [EMAIL PROTECTED] wrote: It looks pretty good. I'm guessing the system scdl being used by the web app doesn't include the scdl for your binding. The way the sample webapps are done right now with all the jars going into the webapp lib you need to add all extensions to the system scdl being used. In you web.xml there's a parameter systemScdlPath which is set to /META-INF/sca/webapp.system.scdl. That will pick up the resource from the webapp-host.jar. Update that file or copy it somewhere else and update the systemScdlPath to point at the new file, and add in your jsonrpc scdl elements. Once we get extension plugabilty going properly in the samples this wont be necessary. ...ant On 8/24/06, Bert Lamb [EMAIL PROTECTED] wrote: Ok, my I tried to send this email earlier, but it bounced as spam, so I'm going to try again with a link to my attachment and see if that helps So I'm sure it is something stupid, but I'm missing something. I've got the sample webapp packaged correctly (I think) and it was giving the error about the unrecognized element binding.jasonrpc. I then added my jsonrpc-1.0-SNAPSHOT.jar that I thought was at least mocked up correctly to get me onto the next error, but it doesn't seem to be getting picked up, and I still have the unrecognized element binding.jsonrpc error. Here is a link to a zip of my binding.jsonrpc source tree. Any ideas? http://bertlamb.com/binding.jsonrpc.zip Thanks! -Bert On 8/18/06, ant elder [EMAIL PROTECTED] wrote: Hi Bert, I agree there's going to be some challenges to solve to integrate REST well with Tuscany, I'll stay out of that for now and focus on how to get you started with bindings. Implementing a simple binding would be a good place to start so if you want to port over the old jsonrpc binding that would be great. The code for that is at, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/sca/bindings/binding.jsonrpc/ , and there's a sample, http://svn.apache.org/repos/asf/incubator/tuscany/branches/java-post-M1/samples/sca/helloworldjsonrpc/ . You could download the Tuscany M1 distribution if you want to see the sample running. I'd start by taking the sample and getting it to fit in with the new code base - convert the SCDL to the new format, and get the war packaging correct. You could use the Axis2 WS sample as a model for that which is at, http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/helloworldws/ . (The WAR packaging is going to change once I finish the TuscanyServletListener and ServletHost work, I'll let you know when that goes in) Once you get the WAR right when you deploy it to tomcat you should see an exception about an unrecognized element: binding.jsonrpc, thats because Tuscany doesn't have a binding for it so now you need to convert the binding over to the new Tuscany runtime. There's several bindings to use as models, the RMI or echo ones are simple, the Axis2 uses the ServletHost which you'll also need to do: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.rmi/ http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/sca/echo.binding/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/ Copy the existing echo or RMI binding, rename all 'rmi' to jsonrpc', then try to hook up the JSONRPCEntryPointServlet based on what the Axis2 binding is doing. You wont need the RMIReference or RMIInvoker classes as jsonrpc only supports services. There's also a binding using DWR instead of json-rpc-java which you port to the new runtime and its a bit more interesting as it also supports references (well, externalServices) so you could look at that as well if you're interested: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/ajax/. If you search back in the dev list archives there's a few mails where we talk about what these two binding do. Hope this helps, ...ant On 8/17/06, Bert Lamb [EMAIL PROTECTED] wrote: On 8/16/06, Jeremy Boynes [EMAIL PROTECTED] wrote: In terms of the basic transport, in M1 we had a JSON-RPC binding that supported JSON encoded data over HTTP. We have not got around yet to porting that to the new structure in the trunk. Looking at that would be a good way to dig into how Tuscany works. I can make an attempt to try and port the jsonrpc binding from M1 over to trunk style extensions if this would be appreciated. I agree that should help me get an understanding of how some of Tuscany works. Oisin may have been referring to how REST would impact the programming
Re: Problems with porting jsonrpc binding
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
Re: [jira] Created: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
Jojo, Thanks, Any chance you could provide an svn diff patch with what is in the current svn codebase? Thanks. Jojo wrote: Hi, I was able to resolve the issues and run all the test cases. I have attached a zip file to the JIRA, which you can find at: https://issues.apache.org/jira/secure/attachment/12339477/tuscany-sca-tools.zip In the M1 version, there was a dependancy on tuscany\sca\model\src\main\java\org\apache\tuscany\model\util\XMLNameUtil. This is not available in the current release. So I have re-packeged this file into the tools package. On 8/23/06, Jojo [EMAIL PROTECTED] wrote: Hi Ant, Thanks for looking into this. Unfortuately I had a machine crash sometime back and trying to recover. So I won't be able to give you a patch. And the code is not yet in SVN. I am trying to run it usig Maven. I will try to give you a zip file with the code. Thanks and regards, jojo. On 8/23/06, ant elder [EMAIL PROTECTED] wrote: Jojo, it should be picking up the Woodstox jar (eg, wstx-asl-2.9.3.jar), this error is saying it can't find that jar. Is that jar in your classpath? Could you describe a bit more how you're try to run this - in eclipse or mvn, is the code in SVN so I can try? ...ant On 8/22/06, Jojo [EMAIL PROTECTED] wrote: Hi, I was trying to get some java2wsdl test case running, but got stuck with the following error : javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java :72) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:176) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92) at javax.xml.stream.XMLInputFactory.newInstance( XMLInputFactory.java:136) I remember seeing this problem previously discussed in the thread [Axiom and classloaders, was: svn commit: r429905] and was fixed subsequently. But the fix was not discussed in the tread. I understand this is a classloader/classpath issue. Can someone tell me what was the fix ? The same fix need to be applied to the sca-tools project. Thanks! jojo. On 8/22/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Rick, I can with this. Please let me know what else needs to be done to the existing code in M1 in the context of M2 after you have moved the code over to the current trunk. Thanks - Venkat On 8/22/06, Rick Rineholt (JIRA) tuscany-dev@ws.apache.org wrote: Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- 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] -- Warm regards, jojo. - 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]
Re: [C++] Coding convention for #ifndef in our includes
Pete Robbins wrote:
I prefer the SCA style rather than the ones in SDO. The full path is
better
as well so
#ifndef commonj_sdo_changeddataobjectlist_h
is what I would use.
However, I don't think this affects the readabillity of the code so I
don't
propose we change them all. We need to update the licence header in every
file at some point so we could change these at that time if necessary.
Cheers,
PS. Let's not get into the discussion on where you place your opening
{.
If the code is readable then it's ok by me rather than getting anal on
code
formating standards ;-)
OK I agree with you that we don't need to change the existing ones at
this point, I was just thinking about what to do in new files.
+1 on the SCA style, that's what I'll use from now on.
I'm with you on keeping the code readable while staying open to
different coding styles. Like I said below I usually try to follow the
style I find in existing code and so far I've found the Tuscany C++ code
quite readable.
On 23/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I see two different coding conventions for the usual
#ifndef/#define/#endif in our include files:
#ifndef tuscany_sca_model_binding_h in tuscany::sca::model::Binding.h
#ifndef _CHANGEDDATAOBJECTLIST_H_ in
commonj::sdo::ChangedDataObjectList.h
Can we decide on a common convention? I have used both conventions in
the past, so I'm OK with either but think it'd be nicer if we could pick
one and stick to it.
Until we make a decision I'll follow my old code maintainer habit to
stick to the scheme I see in the code around what I'm adding/changing.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Das Logging Framework
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]
Re: Das Logging Framework
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]
Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
Hi Rick, Could you let me know the error you were getting from this since it appears to be caused by a patch for Tuscany-661? Things build on my machine and presumably on Jervis'. Jim Begin forwarded message: From: [EMAIL PROTECTED] Date: August 24, 2006 4:35:09 AM PDT To: tuscany-commits@ws.apache.org Subject: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/ binding.axis2/pom.xml Reply-To: tuscany-dev@ws.apache.org Author: rineholt Date: Thu Aug 24 04:35:06 2006 New Revision: 434372 URL: http://svn.apache.org/viewvc?rev=434372view=rev Log: use 2.1 assembly plugin in for now seems to work Modified: incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml Modified: incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/ bindings/binding.axis2/pom.xml? rev=434372r1=434371r2=434372view=diff == --- incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml (original) +++ incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml Thu Aug 24 04:35:06 2006 @@ -167,14 +167,13 @@ /dependencies !-- The assembly plugin cannot understand maven1 pom -- -!-- build defaultGoalinstall/defaultGoal plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId -version2.2-SNAPSHOT/version +version2.1/version executions execution phasepackage/phase @@ -191,6 +190,5 @@ /plugin /plugins /build - -- /project - 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: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
Hello Jim, If I uncomment that plugin to build the assembly the error I get is below. This had been working but I'm thinking cause we're using SNAPSHOT for the plugin, it got replaced that doesn't like now the fact that Axis is really being retrieved from a legacy (maven 1.x) repo? [DEBUG] Statistics for Scope filter [compile=true, runtime=true, test=false, provided=false, system=false] [DEBUG] The following scope filters were not used: o System [DEBUG] The following artifacts were removed by this filter: jmock:jmock:jar:1.0.1 org.easymock:easymock:jar:2.2 org.apache.tuscany:test:jar:1.0-SNAPSHOT javax.servlet:servlet-api:jar:2.3 cglib:cglib-nodep:jar:2.1_3 org.easymock:easymockclassextension:jar:2.2 [WARNING] Attempting to build MavenProject instance for Artifact of type: jar; constructing POM artifact instead. [DEBUG] axis2-kernel: using locally installed snapshot [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: axis2:axis2-kernel POM Location: C:\Documents and Settings\rineholt\.m2\repository\axis2\axis2-kernel\SNAPSHOT\axis2-kernel-SNAPSHOT.pom Reason: Not a v4.0.0 POM. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:290) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:92) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:62) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:46) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:82) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:269) ... 18 more Caused by: org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0 POM. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1299) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1270) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:471) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:225) at
Re: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
I'm fairly certain this is due to an updated snapshot. If I grab the maven-assembly-plugin-2.2-SNAPSHOT.jar jar from a machine I have not done a build on lately and has a older date that plugin seems to work fine. Rick wrote: Hello Jim, If I uncomment that plugin to build the assembly the error I get is below. This had been working but I'm thinking cause we're using SNAPSHOT for the plugin, it got replaced that doesn't like now the fact that Axis is really being retrieved from a legacy (maven 1.x) repo? [DEBUG] Statistics for Scope filter [compile=true, runtime=true, test=false, provided=false, system=false] [DEBUG] The following scope filters were not used: o System [DEBUG] The following artifacts were removed by this filter: jmock:jmock:jar:1.0.1 org.easymock:easymock:jar:2.2 org.apache.tuscany:test:jar:1.0-SNAPSHOT javax.servlet:servlet-api:jar:2.3 cglib:cglib-nodep:jar:2.1_3 org.easymock:easymockclassextension:jar:2.2 [WARNING] Attempting to build MavenProject instance for Artifact of type: jar; constructing POM artifact instead. [DEBUG] axis2-kernel: using locally installed snapshot [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: axis2:axis2-kernel POM Location: C:\Documents and Settings\rineholt\.m2\repository\axis2\axis2-kernel\SNAPSHOT\axis2-kernel-SNAPSHOT.pom Reason: Not a v4.0.0 POM. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:290) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:92) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:62) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:46) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:82) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:269) ... 18 more Caused by: org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0 POM. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1299) at
Re: REST bindings for Tuscany SCA runtime
What do you think about the following approach: a) If you put no annotations in your code then you have to stick to the fixed pattern with fixed method names, and you write the side SCDL file that turns your code into a component and publishes the REST endpoint. b) If you want more flexibility to map state changes to nicer method names then you use annotations as your were proposing earlier in this thread. The annotations also allow you to completely avoid writing SCDL and specify the details of the binding like the base URI for the resources... Thoughts? These sound like good approaches to me - the one thing that I'm scratching my head about a bit is the create-resource and delete-resource support. The read-resource and update-resource ops are fine, because we have a resource (i.e. the thing that has just been coded). What's implicit here, though, is that there is always a fixed set of resources - the ones that you have just 'deployed'. So the create/delete ops can never be used because things are just set up that way. BTW, this is probably ok and it does match nicely with the accepted admin practice of disabling PUT and DEL in real webservers (as observed previously in this thread). I would be happy enough to leave off the create/delete support for the immediate future :) You have .put and .get in the client example, maybe the .post should be something like customers.post(uri, state-diff) Ah! interesting, I never thought about that before, looks like there could be a pretty good fit with SDO with the following: customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ... This would be an interesting usage of SDO change summaries IMO, obviously just as an option as you should be able to format your state diff in any format you want as long as it's understood by your application. What do you think? This sounds like a nifty fit for sure. But now I have to go and read that SDO spec in more detail, because I know too little about it :) I like the general approach of going down the diff route because if you do it right then you can undo/redo changes to the data, which is neat feature, provided you are willing to store all of the diffs in a timeline. I'll go off and read that spec again. I just love reading specs ;) Are we close enough to condense a summary on the topic of REST and SCA? This would be good white paper material BTW. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
I was getting the same error and I commented the build out in r434255. But Rick restored after that and removed it again. :-) Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 10:04 AM Subject: Re: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml Hello Jim, If I uncomment that plugin to build the assembly the error I get is below. This had been working but I'm thinking cause we're using SNAPSHOT for the plugin, it got replaced that doesn't like now the fact that Axis is really being retrieved from a legacy (maven 1.x) repo? [DEBUG] Statistics for Scope filter [compile=true, runtime=true, test=false, provided=false, system=false] [DEBUG] The following scope filters were not used: o System [DEBUG] The following artifacts were removed by this filter: jmock:jmock:jar:1.0.1 org.easymock:easymock:jar:2.2 org.apache.tuscany:test:jar:1.0-SNAPSHOT javax.servlet:servlet-api:jar:2.3 cglib:cglib-nodep:jar:2.1_3 org.easymock:easymockclassextension:jar:2.2 [WARNING] Attempting to build MavenProject instance for Artifact of type: jar; constructing POM artifact instead. [DEBUG] axis2-kernel: using locally installed snapshot [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: axis2:axis2-kernel POM Location: C:\Documents and Settings\rineholt\.m2\repository\axis2\axis2-kernel\SNAPSHOT\axis2-kernel-SNAPSHOT.pom Reason: Not a v4.0.0 POM. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:290) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:92) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:62) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:46) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:82) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:269) ... 18 more Caused by: org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0 POM. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1299) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1270)
Re: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml
Well the plan was to back off to 2.1 version of the plugin. I tried while in the axis2 binding directory and it worked. And I checked it in. But when I did a build from the root it failed so ... backed it out again :-) Raymond Feng wrote: I was getting the same error and I commented the build out in r434255. But Rick restored after that and removed it again. :-) Thanks, Raymond - Original Message - From: Rick [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 10:04 AM Subject: Re: Fwd: svn commit: r434372 - /incubator/tuscany/java/sca/bindings/binding.axis2/pom.xml Hello Jim, If I uncomment that plugin to build the assembly the error I get is below. This had been working but I'm thinking cause we're using SNAPSHOT for the plugin, it got replaced that doesn't like now the fact that Axis is really being retrieved from a legacy (maven 1.x) repo? [DEBUG] Statistics for Scope filter [compile=true, runtime=true, test=false, provided=false, system=false] [DEBUG] The following scope filters were not used: o System [DEBUG] The following artifacts were removed by this filter: jmock:jmock:jar:1.0.1 org.easymock:easymock:jar:2.2 org.apache.tuscany:test:jar:1.0-SNAPSHOT javax.servlet:servlet-api:jar:2.3 cglib:cglib-nodep:jar:2.1_3 org.easymock:easymockclassextension:jar:2.2 [WARNING] Attempting to build MavenProject instance for Artifact of type: jar; constructing POM artifact instead. [DEBUG] axis2-kernel: using locally installed snapshot [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: axis2:axis2-kernel POM Location: C:\Documents and Settings\rineholt\.m2\repository\axis2\axis2-kernel\SNAPSHOT\axis2-kernel-SNAPSHOT.pom Reason: Not a v4.0.0 POM. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create assembly: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:290) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error retrieving POM of module-dependency: axis2:axis2-kernel:jar:SNAPSHOT; Reason: Not a v4.0.0 POM. at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:92) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:62) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:46) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:82) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:269) ... 18 more Caused by:
[C++] Changes to tuscany::sca::model
Hi, I'm going to leave the SupplyChain scenario alone for a day or two, to leave people time to take a look at it, comment and see if/how the SCDL artifacts can be simplified or done better before integrating the actual implementation logic of the supplychain management components. In the meantime, I'm starting to make changes to the SCDL model in tuscany::sca::model to match the logical model for the 0.95 recursive composition SCDL. This will bring the model classes closer to the diagram I had posted a while back: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/cpp/diagrams/service.jpg. This will include the following changes: - finish aligning the model classes with the 0.95 terminology - separate component and component type - support multiple instances of a type configured differently - refactor subsystem/module into composite - support for includes I'll adjust the rest of the runtime as necessary to keep it building and working, but I'll try to minimize the changes, and will leave TODO comments where I feel that more work is required later. I should be able to start checking in some of the changes at the end of the day or tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto discovering WSDL
It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader(SPI) implementation. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG
Re: Auto discovering WSDL
Some comments in line. Thanks, Raymond - Original Message - From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 11:08 AM Subject: Re: Auto discovering WSDL It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) I suggest that we use QName to represent different types of artifacts and it should be extensible. . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) I think we should align it with the SCA scope container concept. . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader(SPI) implementation. Probably we should get the framework in place before add more extensions. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Changes to tuscany::sca::model
Excellent stuff... another thing that we haven't got around to yet. I'm still playing around with different ways of making pluggable extensions so I'll just merge what you check in with what I'm looking at. Cheers, On 24/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I'm going to leave the SupplyChain scenario alone for a day or two, to leave people time to take a look at it, comment and see if/how the SCDL artifacts can be simplified or done better before integrating the actual implementation logic of the supplychain management components. In the meantime, I'm starting to make changes to the SCDL model in tuscany::sca::model to match the logical model for the 0.95 recursive composition SCDL. This will bring the model classes closer to the diagram I had posted a while back: http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/cpp/diagrams/service.jpg. This will include the following changes: - finish aligning the model classes with the 0.95 terminology - separate component and component type - support multiple instances of a type configured differently - refactor subsystem/module into composite - support for includes I'll adjust the rest of the runtime as necessary to keep it building and working, but I'll try to minimize the changes, and will leave TODO comments where I feel that more work is required later. I should be able to start checking in some of the changes at the end of the day or tomorrow. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto discovering WSDL
On Aug 24, 2006, at 11:08 AM, Yang ZHONG wrote: It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. I think this would be great. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, Could you explain how an IProject relates to this? however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. Could you also explain a bit more about what you see as SCA composite scoping? I was thinking the system service would be module scoped (i.e. singleton per composite it is already deployed as), or associated on the CompositeComponent directly, in which case the classloader lookup is probably not necessary (the option of using the property extension mechanism). I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader (SPI) implementation. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. Np thanks for doing this. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build error
I brought this up awhile back and Raymond seemed to recognize the error. I don't think a fix or workaround was ever suggested suggested. [surefire] testTransformation2(org.apache.tuscany.databinding.TransformationTest Case) Time elapsed: 0.06 sec ERROR! java.lang.NoClassDefFoundError: com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLea fInfoImpl (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:123) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeT ypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java: 97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeMode lBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex tImpl.java:343) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.ja va:215) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 55) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auto discovering WSDL
Yes, doable. After I roll out API and SPI (soon I hope) for review, could you provide the Loader(SPI) implementation for WSDL please? Thanks. On 8/24/06, ant elder [EMAIL PROTECTED] wrote: Hi Yang, this sounds great and very comprehensive! It could take some time to complete it all so can i tell you the parts that would be useful to me to have sooner rather than later to help with Axis2 and E4X, maybe you could look at implementing some of these bits first? For now just WSDL 1.1 support using WSDL4J. - get a WSDL4J PortType for a portType QName and optional wsdl location - get a WSDL4J Definition from a service QName and optional wsdl location - get a WSDL4J Port from a service QName and port name, and an optional wsdl location (actually, i don't really need the Port, just its endpoint location string) Scoping seems complicated, scoped by application seems like it would work with all the samples I'd like to get going. I guess that means app classloader or maybe something to do with DeploymentContext. It would be nice to also support namespace reuse within applications when using the optional location. For now just locating wsdl bundled with an application is ok for me, and I'd like it to support automatically find all wsdl anywhere within the application folder structure, but other's don't sound so keen on that so maybe configurable to support locating from anywhere or just a specific folder. How doable does all that sound? ...ant On 8/24/06, Yang ZHONG [EMAIL PROTECTED] wrote: It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader(SPI) implementation. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG -- Yang ZHONG
Ruby Header-replace script
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]
[jira] Updated: (TUSCANY-579) getString on Date field results in IllegalArgumentException
[ http://issues.apache.org/jira/browse/TUSCANY-579?page=all ]
Brian Murray updated TUSCANY-579:
-
Attachment: api_test.xsd
This is the resource needed for the test case.
getString on Date field results in IllegalArgumentException
---
Key: TUSCANY-579
URL: http://issues.apache.org/jira/browse/TUSCANY-579
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Attachments: api_test.xsd, Tuscany579.patch, Tuscany579.patch,
TypeConversionTestCase.java
On page 146 of V2.01 of the spec, it is stated that conversion from Date to
String is supported. However, getString on Date type results in an
IllegalArgumentException. Here is a code segment:
public void testShowErrorsInSimpleFormat() throws Exception
{
DataObject test_obj = DataFactory.INSTANCE.create(API_TEST_TYPE);
Date current_date = new Date(System.currentTimeMillis());
// getString does not work on Date type
test_obj.setDate(dateVal, current_date);
String returned_string = test_obj.getString(dateVal); //Gives
IllegalArgumentException
}
And here is the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:sdo=commonj.sdo
xmlns:simple=http://www.example.com/api_test;
targetNamespace=http://www.example.com/api_test;
xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/
xsd:element name=apiTestElem type=simple:APITest/
xsd:complexType mixed=true name=APITest
xsd:sequence
xsd:element name=stringVal type=sdo:String/
xsd:element name=booleanVal type=sdo:Boolean/
xsd:element name=booleanVal2 type=sdo:Boolean/
xsd:element name=byteVal type=sdo:Byte/
xsd:element name=stringVal2 type=sdo:String/
xsd:element name=decimalVal type=sdo:Decimal/
xsd:element name=decimalVal2 type=sdo:Decimal/
xsd:element name=intVal type=sdo:Int/
xsd:element name=floatVal type=sdo:Float/
xsd:element name=doubleVal type=sdo:Double/
xsd:element name=dateVal type=sdo:Date/
xsd:element name=shortVal type=sdo:Short/
xsd:element name=longVal type=sdo:Long/
xsd:element maxOccurs=unbounded minOccurs=0
name=children type=simple:APITest/
xsd:element name=bytesVal type=sdo:Bytes/
xsd:element name=integerVal type=sdo:Integer/
xsd:element name=charVal type=sdo:Character/
/xsd:sequence
/xsd:complexType
I originally thought that also getDate was not working on String, but this
was an error in my test case. I had been setting the String value to be
Date.toString(). Fuhwei correctly pointed out that the String format that
would allow conversion is given on page 72 of the specification and is
different than what is returned by Date.toString(). I have tested with the
correct String format and found that getDate works, so clearly this is not an
error. However, I wonder if it would be a good idea to aditionally support
the String format that results from Date.toString().
--
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-582) Date fields sometimes not preserved when using DataHelper.
[ http://issues.apache.org/jira/browse/TUSCANY-582?page=all ]
Brian Murray updated TUSCANY-582:
-
Attachment: DateConversionTestCase.java
Tuscany582.patch
Some minor revisions resulting from a code review with a peer.
Date fields sometimes not preserved when using DataHelper.
--
Key: TUSCANY-582
URL: http://issues.apache.org/jira/browse/TUSCANY-582
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Priority: Minor
Attachments: DateConversionTestCase.java,
DateConversionTestCase.java, DateConversionTestCase.java,
DateConversionTestCase.java, Tuscany582.patch, Tuscany582.patch,
Tuscany582.patch
While I find it mildly surprising that you can convert from a Day to a Date,
I would expect that in doing so the Day (Date.getDate()) value within Date
would be accurate (even if all other fields are meaningless).
// The output of each println (from a single run) is placed in comments
beside it
public void testShowErrorsInSimpleFashion() throws Exception
{
Date temp = new Date(System.currentTimeMillis());
// In following sequence - would expect the Day value (here, 21) to be
maintained.
System.out.println(temp = + temp); // temp = Fri Jul 21 03:51:01 EDT
2006
String day = data_helper.toDay(temp);
System.out.println(day = + day); // day = ---21 EDT
Date date2 = data_helper.toDate(day);
System.out.println(date2 = + date2); // date2 = Thu Feb 29 23:00:00
EST 1968
String day2 = data_helper.toDay(date2);
System.out.println(day2 = + day2); // day2 = ---29 EST
}
When I look in DataHelperImpl.java, I see a series of Date Patterns. It
seems that Day is being matched to an earlier pattern than the expected one
(the expected one is ---dd zz). When I move that pattern to first in the
list, the outcome is affected. Were it not matching an earlier pattern, I
would think that moving the correct one to the front of the list would not
have an effect.
Leaving DataHelperImpl.java unaltered, Day = 21 EDT, and Day2 = 29 EST (in
the case above). However, if I put the appropriate pattern first in the list,
Day2 is instead = 20 EST. Interestingly, it is still not the correct day
(21).
Frank pointed out that there have been recent updates to DataHelper, however
I've retested with build level 425652 and see the same behavior.
Side note:
The following is not a JIRA issue, but it is related. In the second table
on page 146 the Date conversions for most types are essentially to the same
type, to Date, and to String. It seems that several more are possible. The
following seem capable of being added:
DateTime- Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
Duration, Day
Duration-Month, MonthDay, YearMonth, YearMonthDay, Time, Year,
DateTime, Day
MonthDay-Month, Day
YearMonth-Month, Year
YearMonthDay-Month, Year, Day, YearMonth, MonthDay
--
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: Auto discovering WSDL
Hi Yang, this sounds great and very comprehensive! It could take some time to complete it all so can i tell you the parts that would be useful to me to have sooner rather than later to help with Axis2 and E4X, maybe you could look at implementing some of these bits first? For now just WSDL 1.1 support using WSDL4J. - get a WSDL4J PortType for a portType QName and optional wsdl location - get a WSDL4J Definition from a service QName and optional wsdl location - get a WSDL4J Port from a service QName and port name, and an optional wsdl location (actually, i don't really need the Port, just its endpoint location string) Scoping seems complicated, scoped by application seems like it would work with all the samples I'd like to get going. I guess that means app classloader or maybe something to do with DeploymentContext. It would be nice to also support namespace reuse within applications when using the optional location. For now just locating wsdl bundled with an application is ok for me, and I'd like it to support automatically find all wsdl anywhere within the application folder structure, but other's don't sound so keen on that so maybe configurable to support locating from anywhere or just a specific folder. How doable does all that sound? ...ant On 8/24/06, Yang ZHONG [EMAIL PROTECTED] wrote: It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader(SPI) implementation. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG
Re: Text for main page of Tuscany website
It seems logicial to introduce the project first and then display a diagram. This would be the first time users learn about Tuscany. Have we decided which diagram we'd like to settle on? There were two posted with David's prototype. Haleh On 8/24/06, ant elder [EMAIL PROTECTED] wrote: Could the General Tuscany diagram would go here be moved from being right at the bottom to nearer the top so you see it all without having to scroll the page down? ...ant On 8/24/06, haleh mahbod [EMAIL PROTECTED] wrote: Hello Tuscany community, Please review the following text as a proposed text for our main web page. Jim, Thanks for your feedback. I tried to capture your comments in the new writeup. Please feel free to re-write this if you think it needs improvement :) Haleh --- Start of text --- Welcome to the Apache Tuscany free open source project that is licensed under version 2 of the Apache Licensehttp://www.apache.org/licenses/LICENSE-2.0_. This project is currently in incubation within the Apache incubator. The aim of the Apache Tuscany project is to create, as a community, a robust infrastructure that simplifies the development of SOA-based systems. Apache Tuscany is based on independent technologies that together provide one complete infrastructure which caters to this goal. This includes the following: · Service Component Architecture (SCA) enables composition of service networks through assembly of existing and new services. Apache Tuscany implements SCA in Java and C++. Tuscany SCA runtime can easily be extended to support any communication transport, qualities of service or programming model and can be used in conjunction with other technologies such as Spring, Axis and Celtix. · Service Data Object (SDO) provides a uniform interface for handling different forms of data that can exist in a network of services and provides the mechanism for tracking changes in data. Apache Tuscany provides Java and C++ implementations for SDO. · Service Data Access (DAS) provides a uniform interface for interacting with persistent data when using SDO. Apache Tuscany provides a Java implementation for DAS. SCA and SDO technologies can be used independent of one another. The specifications for these technologies are located at www.osoa.org . Apache Tuscany project provides input to the specifications. Please join us to develop this innovative infrastructure and/or provide feedback based on real use case scenarios which will help Apache Tuscany become a first class solution for simplifying the development of SOA-based systems. General Tuscany diagram would go here On 8/17/06, Jim Marino [EMAIL PROTECTED] wrote: Thanks Haleh for taking the time to write this up again...more comments inline. Jim On Aug 16, 2006, at 6:34 PM, haleh mahbod wrote: Jim, Thanks for the comments. I took a look at the links and your comments. How about this write-up? Welcome to the Apache Tuscany free open source project that is licensed under version 2 of the Apache Licensehttp://www.apache.org/licenses/LICENSE-2.0_. This project is currently in incubation within the Apache incubator. The aim of the Apache Tuscany is to create, as a community, a robust framework that simplifies the development of SOA-based systems through seamless handling of many infrastructure and data handling complexities which exist in heterogeneous Service Oriented Architecture (SOA) environment. IMO the first statement needs to be really direct and as free of buzzwords as possible since it is the first thing people are going to judge us on. I'd try and limit the use of SOA as much as possible since the term is abused these days. I'd also try and not talk about business problems since we are targeting primarily systems developers (to join the project) and secondarily end-user applications developers. With that in mind, I would say Tuscany is infrastructure (as opposed to a framework like Rails, RIFE, parts of Spring, etc.) that simplifies the development of SOA-based systems. It does so by providing technology for composing service networks (service assemblies) based on SCA and technologies for managing data in that environment based on SDO. At some point I also think we need to make it clear that SCA, SDO and DAS are independent technologies. If I had to characterize the message I would want to send the two constituencies it would be: - system developers: the stuff we're working on involves solving really hard problems and you should be part of building out the next generation infrastructure and doing innovative things. - application developers: our technologies are cool, work with stuff you already know, and will enable you to build really
Re: [jira] Updated: (TUSCANY-642) Composite references and services - model and runtime representations
I posted a new patch for this but have not received the corresponding email. In case others are on the same boat, I append the text of the post. Here's a new patch that modifies CompositeBuilderTestCase to verify that the Connector also works for composite services and references. This patch also includes a more complete sample with an inner composite that has an inner service, inner component and inner reference; the inner composite is wired from an outer composite to a sibling component and the inner component then invokes the outer component. This patch also fixes a bug, where the loader for implementation composite was not being called, by adding a component to composite.scdl in sca/test, sca/commands/launcher and sca/runtime/webapp-host. Finally, for some reason having to do with class loaders, the class for the sample's inner service interface was not being found. This has not been resolved, at least not well enough. To get over the hurdle I hacked LoaderUtil.loadClass to try the old class loader if the one in the deployment context does not work. This seems to work but is obviously not adequate (not to mention the glaring println). In the interest of making progress, I include the hack in this patch. Hopefully the real fix can be incorporated during commit of this patch or in a subsequent one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-663) XPATH doesnt support dots in names (treats them as indices)
XPATH doesnt support dots in names (treats them as indices)
---
Key: TUSCANY-663
URL: http://issues.apache.org/jira/browse/TUSCANY-663
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Ed Slattery
The XPATH subset from the specification uses NCname for names, so in theory
www.xxx.yyy.zzz is a vaild name, which may either be a field called
www.xxx.yyy.zzz or a many valued
field called www.xxx.yyy at offset zzz
The C++ implementation restricts this and assumes all [] or . are indices.
Fix this by parsing the XPATH token, then checking if the token is a valid
property name for the object, then
if not, looking for the last . or [ to see if theres an index.
Heres the details of the grammar...
path ::= (scheme ':')? '/'? (step '/')* step
scheme ::= [^:]
step ::= '@'? property
| property '[' index_from_1 ']'
| property '.' index_from_0
| reference '[' attribute '=' value ']'
| ..
property ::= NCName ;; may be simple or complex type
attribute ::= NCName ;; must be simple type
reference :: NCName ;; must be DataObject type
index_from_0 ::= Digits
index_from_1 ::= NotZero (Digits)?
value ::= Literal
| Number
| Boolean
Literal ::= '' [^]* ''
| ' [^']* '
Number ::= Digits ('.' Digits?)?
| '.' Digits
Boolean ::= true
| false
NotZero ::= [1-9]
Digits ::= [0-9]+
;; leading '/' begins at the root
;; .. is the containing DataObject, using containment properties
--
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-420) Refactoring of Rhino code in the JavaScript container
[ http://issues.apache.org/jira/browse/TUSCANY-420?page=all ] ant elder closed TUSCANY-420. - Resolution: Fixed Got fixed in the port to the new runtime Refactoring of Rhino code in the JavaScript container - Key: TUSCANY-420 URL: http://issues.apache.org/jira/browse/TUSCANY-420 Project: Tuscany Issue Type: Improvement Components: Java SCA JavaScript Container Affects Versions: Java-M2 Reporter: ant elder Fix For: Java-M2 Need to do some refactoring of the classes for interacting with Rhino in order to implement some of the new SCA JavaScript functions planned -- 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-642) Composite references and services - model and runtime representations
[ http://issues.apache.org/jira/browse/TUSCANY-642?page=all ] Ignacio Silva-Lepe updated TUSCANY-642: --- Attachment: InnerComposite.patch Here's a new patch that modifies CompositeBuilderTestCase to verify that the Connector also works for composite services and references. This patch also includes a more complete sample with an inner composite that has an inner service, inner component and inner reference; the inner composite is wired from an outer composite to a sibling component and the inner component then invokes the outer component. This patch also fixes a bug, where the loader for implementation composite was not being called, by adding a component to composite.scdl in sca/test, sca/commands/launcher and sca/runtime/webapp-host. Finally, for some reason having to do with class loaders, the class for the sample's inner service interface was not being found. This has not been resolved, at least not well enough. To get over the hurdle I hacked LoaderUtil.loadClass to try the old class loader if the one in the deployment context does not work. This seems to work but is obviously not adequate (not to mention the glaring println). In the interest of making progress, I include the hack in this patch. Hopefully the real fix can be incorporated during commit of this patch or in a subsequent one. Composite references and services - model and runtime representations - Key: TUSCANY-642 URL: http://issues.apache.org/jira/browse/TUSCANY-642 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Assigned To: Ignacio Silva-Lepe Fix For: Java-Mx Attachments: CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt, InnerComposite.patch Support is added to represent composite references and services (those in a composite and without a binding) in the model and runtime. The CompositeBuilder is updated to build a composite component that includes composite references and services without bindings. -- 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: [jira] Updated: (TUSCANY-642) Composite references and services - model and runtime representations
O.K. I'll take a look. I've got an unfinished commit to do once I get access to svn on my machine back up (the repo may be down). Jim On Aug 24, 2006, at 1:05 PM, Ignacio Silva-Lepe wrote: I posted a new patch for this but have not received the corresponding email. In case others are on the same boat, I append the text of the post. Here's a new patch that modifies CompositeBuilderTestCase to verify that the Connector also works for composite services and references. This patch also includes a more complete sample with an inner composite that has an inner service, inner component and inner reference; the inner composite is wired from an outer composite to a sibling component and the inner component then invokes the outer component. This patch also fixes a bug, where the loader for implementation composite was not being called, by adding a component to composite.scdl in sca/test, sca/commands/launcher and sca/runtime/ webapp-host. Finally, for some reason having to do with class loaders, the class for the sample's inner service interface was not being found. This has not been resolved, at least not well enough. To get over the hurdle I hacked LoaderUtil.loadClass to try the old class loader if the one in the deployment context does not work. This seems to work but is obviously not adequate (not to mention the glaring println). In the interest of making progress, I include the hack in this patch. Hopefully the real fix can be incorporated during commit of this patch or in a subsequent one. - 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: Auto discovering WSDL
Comment below. Thanks. On 8/24/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 24, 2006, at 11:08 AM, Yang ZHONG wrote: It has been one full day since Ant proposed a go for registry and Jim agreed. If no one oppose, I'm going to contribute a registry. I think this would be great. The registry will support . different Symbol Spaces (type, top level element, message, portType/interface, etc.) . multiple scopings (ClassLoader, location, Eclipse IProject, composite, etc.) . different scope delegations (no delegation, PARENT_FIRST, PARENT_LAST) . multi-dimension scopings (location vs. ClassLoader/IProject, etc) and registry aggregation (NameSpace aggregation) . automatic locate on demand . automatic load on demand . automatic refresh on demand . multi-threading . weakly/softly referencing scopes (it's user's responsibility not to strong reference key from value directly or *indirectly*, it's recommended to change such strong reference if any to weak/soft one if permanent residency isn't desired) I will also contribute a scoping(SPI) implementation for ClassLoader and Eclipse IProject, Could you explain how an IProject relates to this? ClassLoader and IProject are just Scoping examples, I have no intention to use them for SCA at all, from that perspective, both ClassLoader and IProject are not related, they're not SCA specific. The reason I put them there is just to illustrate the registry is generic and can take any Scoping. Sorry didn't clarify that. however we may need volunteer(s) to contribute/integrate/register SCA (composite) scoping. Could you also explain a bit more about what you see as SCA composite scoping? I was thinking the system service would be module scoped (i.e. singleton per composite it is already deployed as), or associated on the CompositeComponent directly, in which case the classloader lookup is probably not necessary (the option of using the property extension mechanism). I don't have much knowledge about SCA composite scoping yet, and I have no intention to impact that (yet). With generic registry hat on, I don't really count on if SCA uses module or CompositeComponent or ClassLoader or anything else for scope, as long as there's a SPI implementation telling the generic registry what parent scope is for delegation of a given scope. Sorry didn't clarify that. I will contribute a refreshing checking(SPI) implementation based on file/ZipEntry/URL timestamp, however we may need volunteers to contribute/integrate/register locator(SPI) implementation and loader (SPI) implementation. I'll ask for help from Ant to change the Axis2 binding and JavaScript container to use the registry. Thank Ant for the offer. I'll also ask Jim for help with the system service part. Thank Jim for the offer. Np thanks for doing this. I'll try to roll out API and SPI for review as soon as possible. Thanks. -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yang ZHONG
[jira] Created: (TUSCANY-664) Java SCA: C++ container
Java SCA: C++ container --- Key: TUSCANY-664 URL: http://issues.apache.org/jira/browse/TUSCANY-664 Project: Tuscany Issue Type: New Feature Affects Versions: Wish list Reporter: ant elder Priority: Minor Fix For: Wish list It would be interesting to have a C++ container for the Java SCA runtime so C++ components can be invoked from Java. If you know Java and some JNI it should be relatively straight forward to get a C++ container going by copying one of the existing containers (eg JavaScript) and changing it to invoke C++ with JNI. The hard bit will be how to convert between the Java and C++ type systems. One way to do that could be to require SDO, and have an SDO utility to copy between C++ and Java SDO. Apart from having some use in its own rite, having a C++ container for the Java runtime would be a good way to test interoperability with the C++ runtime as we should be able to take all the C++ samples and have them run unchanged in the Java runtime. -- 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-579) getString on Date field results in IllegalArgumentException
[ http://issues.apache.org/jira/browse/TUSCANY-579?page=all ]
Brian Murray updated TUSCANY-579:
-
Attachment: Tuscany579.patch
I've added a new version of Tuscany579.patch. This includes updates to
DataObjectUtil.java to allow setString on a Date field, and getDate on a String
field. The change versus the previous patch is to take advantage of my changes
to DataHelperImpl.java so that the time zone concern Fuhwie pointed out is no
longer an issue. Please note however that Tuscany-581 is a prerequisite to
this fix as a result.
I will shortly include a new test case to go with this fix. The location of
the new test case will be:
tuscany-sdo-imp/src/test/java/org/apache/tuscany/sdo/test/TypeConversionTestCase.java
The test case requires a new XSD. The location of the resource will be:
tuscany-sdo-imp/src/test/resources/api_test.xsd
getString on Date field results in IllegalArgumentException
---
Key: TUSCANY-579
URL: http://issues.apache.org/jira/browse/TUSCANY-579
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Attachments: api_test.xsd, Tuscany579.patch, Tuscany579.patch,
TypeConversionTestCase.java
On page 146 of V2.01 of the spec, it is stated that conversion from Date to
String is supported. However, getString on Date type results in an
IllegalArgumentException. Here is a code segment:
public void testShowErrorsInSimpleFormat() throws Exception
{
DataObject test_obj = DataFactory.INSTANCE.create(API_TEST_TYPE);
Date current_date = new Date(System.currentTimeMillis());
// getString does not work on Date type
test_obj.setDate(dateVal, current_date);
String returned_string = test_obj.getString(dateVal); //Gives
IllegalArgumentException
}
And here is the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:sdo=commonj.sdo
xmlns:simple=http://www.example.com/api_test;
targetNamespace=http://www.example.com/api_test;
xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/
xsd:element name=apiTestElem type=simple:APITest/
xsd:complexType mixed=true name=APITest
xsd:sequence
xsd:element name=stringVal type=sdo:String/
xsd:element name=booleanVal type=sdo:Boolean/
xsd:element name=booleanVal2 type=sdo:Boolean/
xsd:element name=byteVal type=sdo:Byte/
xsd:element name=stringVal2 type=sdo:String/
xsd:element name=decimalVal type=sdo:Decimal/
xsd:element name=decimalVal2 type=sdo:Decimal/
xsd:element name=intVal type=sdo:Int/
xsd:element name=floatVal type=sdo:Float/
xsd:element name=doubleVal type=sdo:Double/
xsd:element name=dateVal type=sdo:Date/
xsd:element name=shortVal type=sdo:Short/
xsd:element name=longVal type=sdo:Long/
xsd:element maxOccurs=unbounded minOccurs=0
name=children type=simple:APITest/
xsd:element name=bytesVal type=sdo:Bytes/
xsd:element name=integerVal type=sdo:Integer/
xsd:element name=charVal type=sdo:Character/
/xsd:sequence
/xsd:complexType
I originally thought that also getDate was not working on String, but this
was an error in my test case. I had been setting the String value to be
Date.toString(). Fuhwei correctly pointed out that the String format that
would allow conversion is given on page 72 of the specification and is
different than what is returned by Date.toString(). I have tested with the
correct String format and found that getDate works, so clearly this is not an
error. However, I wonder if it would be a good idea to aditionally support
the String format that results from Date.toString().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-665) Support multiple ResultSets from Stored Procedures
Support multiple ResultSets from Stored Procedures -- Key: TUSCANY-665 URL: http://issues.apache.org/jira/browse/TUSCANY-665 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Attachments: Tuscany665.txt The DAS needs to be updated to support stored procedures that return multiple ResultSets. -- 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-611) RMI Binding
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=comments#action_12430198 ] ant elder commented on TUSCANY-611: --- Applied Tuscany-RMI-Binding-Formatted-Aug-15-1.diff 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]
[jira] Updated: (TUSCANY-651) Port WSDL2Java and Java2WSDL from M1
[ http://issues.apache.org/jira/browse/TUSCANY-651?page=all ] Jojo Joseph updated TUSCANY-651: Attachment: tuscany-sca-tools.zip Please find the attached file which contais a port of the tools from M1. You can unzip this into tuscany/sca folder. Change to tools folder and run mvn for building. Port WSDL2Java and Java2WSDL from M1 Key: TUSCANY-651 URL: http://issues.apache.org/jira/browse/TUSCANY-651 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Rick Rineholt Fix For: Java-M2 Attachments: tuscany-sca-tools.zip Java2WSDL and WSDL2Java tooling needs to be ported from M1 to facilitate the creation of webservices applications. -- 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-579) getString on Date field results in IllegalArgumentException
[ http://issues.apache.org/jira/browse/TUSCANY-579?page=all ]
Brian Murray updated TUSCANY-579:
-
Attachment: TypeConversionTestCase.java
getString on Date field results in IllegalArgumentException
---
Key: TUSCANY-579
URL: http://issues.apache.org/jira/browse/TUSCANY-579
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Attachments: api_test.xsd, Tuscany579.patch, Tuscany579.patch,
TypeConversionTestCase.java
On page 146 of V2.01 of the spec, it is stated that conversion from Date to
String is supported. However, getString on Date type results in an
IllegalArgumentException. Here is a code segment:
public void testShowErrorsInSimpleFormat() throws Exception
{
DataObject test_obj = DataFactory.INSTANCE.create(API_TEST_TYPE);
Date current_date = new Date(System.currentTimeMillis());
// getString does not work on Date type
test_obj.setDate(dateVal, current_date);
String returned_string = test_obj.getString(dateVal); //Gives
IllegalArgumentException
}
And here is the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:sdo=commonj.sdo
xmlns:simple=http://www.example.com/api_test;
targetNamespace=http://www.example.com/api_test;
xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/
xsd:element name=apiTestElem type=simple:APITest/
xsd:complexType mixed=true name=APITest
xsd:sequence
xsd:element name=stringVal type=sdo:String/
xsd:element name=booleanVal type=sdo:Boolean/
xsd:element name=booleanVal2 type=sdo:Boolean/
xsd:element name=byteVal type=sdo:Byte/
xsd:element name=stringVal2 type=sdo:String/
xsd:element name=decimalVal type=sdo:Decimal/
xsd:element name=decimalVal2 type=sdo:Decimal/
xsd:element name=intVal type=sdo:Int/
xsd:element name=floatVal type=sdo:Float/
xsd:element name=doubleVal type=sdo:Double/
xsd:element name=dateVal type=sdo:Date/
xsd:element name=shortVal type=sdo:Short/
xsd:element name=longVal type=sdo:Long/
xsd:element maxOccurs=unbounded minOccurs=0
name=children type=simple:APITest/
xsd:element name=bytesVal type=sdo:Bytes/
xsd:element name=integerVal type=sdo:Integer/
xsd:element name=charVal type=sdo:Character/
/xsd:sequence
/xsd:complexType
I originally thought that also getDate was not working on String, but this
was an error in my test case. I had been setting the String value to be
Date.toString(). Fuhwei correctly pointed out that the String format that
would allow conversion is given on page 72 of the specification and is
different than what is returned by Date.toString(). I have tested with the
correct String format and found that getDate works, so clearly this is not an
error. However, I wonder if it would be a good idea to aditionally support
the String format that results from Date.toString().
--
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-665) Support multiple ResultSets from Stored Procedures
[ http://issues.apache.org/jira/browse/TUSCANY-665?page=all ] Brent Daniel updated TUSCANY-665: - Attachment: Tuscany665.txt Attaching a patch to support multiple ResultSets Support multiple ResultSets from Stored Procedures -- Key: TUSCANY-665 URL: http://issues.apache.org/jira/browse/TUSCANY-665 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Attachments: Tuscany665.txt The DAS needs to be updated to support stored procedures that return multiple ResultSets. -- 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 site sample
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.
Re: REST bindings for Tuscany SCA runtime
The WebServiceBinding and WebServiceBindingLoader classes in the Axis2 binding are WS specific so you'll need to write new ones of those for your REST binding. Your impls should still extend the BindingBuilderExtension and LoaderExtension SPI classes. Also the Axis2BindingBuilder is specific to the WebServiceBinding so you'll need your own version of that. As to what to do about the service and reference questions now that you're not using WSDL and how to define what operations are exposed, there's been various suggestions in this thread. Probably the easiest approach to get going first while using Axis2s REST support would be by using interface.javawith fixed method names for the REST operations (like what Jean-Sebastien suggested?). Later on once you've made some progress and this thread reaches some conclusions you can work with everyone else here on a more comprehensive solution. ...ant Also, fyi, there's a presentation on Axis2 and REST: http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt On 8/24/06, Sreelatha S [EMAIL PROTECTED] wrote: Hi Ant, As I am still trying to learn about the REST implementation, based of what you have mentioned below I tried to work on the skeleton classes required for the REST binding on Tuscany, by closely following the REST support in Axis 2 and the Axis2Binding classes in Tuscany. I have created RESTServiceServlet class which does something very similar to what the fdoes in Axis2.Which is processing of GET and POST requests. I however, had a few questions: The Axis2Binding extends from the BindingBuilderExtension which is of the type WebServiceBinding, is it appropriate for the RESTBinding class also to extend the BindingBuilderExtension of the type WebServiceBinding? I am asking this as I have the understanding that REST based service is quite different when compared to a WebService. What should we consider as a RESTService and a RESTReference ?In other words how is a RESTService defined and how should we create one, how are its operations exposed, assuming that we are not using a WSDL as in the case of a Webservice. I appreciate any help in furthering my understanding on this. Thanks. ant elder [EMAIL PROTECTED] wrote: Axis2 also has some built in REST support, and as we already have an Axis2 binding it would be relatively easy to get a Tuscany REST binding going using Axis2. All that you need to do is change the Tuscany code to use the Axis2 REST servlet instead of the SOAP one, and change the code where we set up the Axis2 config to set some flags to enable the REST support. With a bit of refactoring of the existing Axis2 binding and changing a few things from private to protected you could probably get something going by subclassing the existing Axis2 binding with minimal new code. I think we should make a better, more 'RESTful' binding than this in the long run, but this approach would be an easy first start. ...ant On 8/22/06, Oisin Hurley wrote: REST is a very generic term, and I think it's more like a resource/ service naming pattern (URL/URI). When we say REST bindings, what are we expecting as the REST Service ? The resource part is really important, but the small interface part is important too, as are the expected behaviours of the interface: i.e., GET is idempotent, PUT will replace a resource, POST will perform a partial update of the state of a resource. IMHO the first place we could go is an XML over HTTP binding and some kind of 'generic' processing method in the service (see [0] for an example of what's RESTful with JAX-WS, which might prompt some ideas). cheers --oh [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: Build error
Hi Raymond, XP Maven version: 2.0.4 Java: C:\apacheSVN\javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a Is there any other info you need? Thanks, --Kevin Raymond Feng wrote: Hi, Kevin. Can you give me more information on how to reproduce the problem (information about your env will be helpful as well since I don't see the problem) so that I debug it? I know the cause and I thought it was fixed by upgrading the surefire plugin. Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 12:14 PM Subject: Build error I brought this up awhile back and Raymond seemed to recognize the error. I don't think a fix or workaround was ever suggested suggested. [surefire] testTransformation2(org.apache.tuscany.databinding.TransformationTest Case) Time elapsed: 0.06 sec ERROR! java.lang.NoClassDefFoundError: com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLea fInfoImpl (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:123) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeT ypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java: 97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeMode lBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex tImpl.java:343) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.ja va:215) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 55) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - 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: Build error
FWIW, I also get this error, along with: [surefire] Running org.apache.tuscany.databinding.JAXBTestCase [surefire] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.541 sec [surefire] [surefire] testTransform(org.apache.tuscany.databinding.JAXBTestCase) Time elap sed: 0.511 sec ERROR! java.lang.LinkageError: loader constraints violated when linking javax/xml/names pace/QName class at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.clinit(Ru ntimeBuiltinLeafInfoImpl.java:186) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeT ypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java: 97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeMode lBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex tImpl.java:343) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.ja va:215) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 55) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 124) ... My env includes: Sun JDK 1.5 (java full version 1.5.0_06-b05), maven version 2.0.4, windows xp (5.1.2600) sp2 - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 5:41 PM Subject: Re: Build error Hi, Kevin. Can you give me more information on how to reproduce the problem (information about your env will be helpful as well since I don't see the problem) so that I debug it? I know the cause and I thought it was fixed by upgrading the surefire plugin. Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 12:14 PM Subject: Build error I brought this up awhile back and Raymond seemed to recognize the error. I don't think a fix or workaround was ever suggested suggested. [surefire] testTransformation2(org.apache.tuscany.databinding.TransformationTest Case) Time elapsed: 0.06 sec ERROR! java.lang.NoClassDefFoundError: com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLea fInfoImpl (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:123) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeT ypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java: 97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeMode lBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex tImpl.java:343) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.ja va:215) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 55) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - 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]
[jira] Resolved: (TUSCANY-579) getString on Date field results in IllegalArgumentException
[ http://issues.apache.org/jira/browse/TUSCANY-579?page=all ]
Frank Budinsky resolved TUSCANY-579.
Resolution: Fixed
Fixed in revision 434519.
getString on Date field results in IllegalArgumentException
---
Key: TUSCANY-579
URL: http://issues.apache.org/jira/browse/TUSCANY-579
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Reporter: Brian Murray
Assigned To: Frank Budinsky
Attachments: api_test.xsd, Tuscany579.patch, Tuscany579.patch,
TypeConversionTestCase.java
On page 146 of V2.01 of the spec, it is stated that conversion from Date to
String is supported. However, getString on Date type results in an
IllegalArgumentException. Here is a code segment:
public void testShowErrorsInSimpleFormat() throws Exception
{
DataObject test_obj = DataFactory.INSTANCE.create(API_TEST_TYPE);
Date current_date = new Date(System.currentTimeMillis());
// getString does not work on Date type
test_obj.setDate(dateVal, current_date);
String returned_string = test_obj.getString(dateVal); //Gives
IllegalArgumentException
}
And here is the XSD:
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:sdo=commonj.sdo
xmlns:simple=http://www.example.com/api_test;
targetNamespace=http://www.example.com/api_test;
xsd:import namespace=commonj.sdo schemaLocation=sdoModel.xsd/
xsd:element name=apiTestElem type=simple:APITest/
xsd:complexType mixed=true name=APITest
xsd:sequence
xsd:element name=stringVal type=sdo:String/
xsd:element name=booleanVal type=sdo:Boolean/
xsd:element name=booleanVal2 type=sdo:Boolean/
xsd:element name=byteVal type=sdo:Byte/
xsd:element name=stringVal2 type=sdo:String/
xsd:element name=decimalVal type=sdo:Decimal/
xsd:element name=decimalVal2 type=sdo:Decimal/
xsd:element name=intVal type=sdo:Int/
xsd:element name=floatVal type=sdo:Float/
xsd:element name=doubleVal type=sdo:Double/
xsd:element name=dateVal type=sdo:Date/
xsd:element name=shortVal type=sdo:Short/
xsd:element name=longVal type=sdo:Long/
xsd:element maxOccurs=unbounded minOccurs=0
name=children type=simple:APITest/
xsd:element name=bytesVal type=sdo:Bytes/
xsd:element name=integerVal type=sdo:Integer/
xsd:element name=charVal type=sdo:Character/
/xsd:sequence
/xsd:complexType
I originally thought that also getDate was not working on String, but this
was an error in my test case. I had been setting the String value to be
Date.toString(). Fuhwei correctly pointed out that the String format that
would allow conversion is given on page 72 of the specification and is
different than what is returned by Date.toString(). I have tested with the
correct String format and found that getDate works, so clearly this is not an
error. However, I wonder if it would be a good idea to aditionally support
the String format that results from Date.toString().
--
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-665) Support multiple ResultSets from Stored Procedures
[ http://issues.apache.org/jira/browse/TUSCANY-665?page=all ] Kevin Williams closed TUSCANY-665. -- Fix Version/s: Java-Mx Resolution: Fixed Verified with revision: 434527 Support multiple ResultSets from Stored Procedures -- Key: TUSCANY-665 URL: http://issues.apache.org/jira/browse/TUSCANY-665 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Reporter: Brent Daniel Assigned To: Brent Daniel Fix For: Java-Mx Attachments: Tuscany665.txt The DAS needs to be updated to support stored procedures that return multiple ResultSets. -- 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: Build error
Hi, Kevin. Can you zip tuscany\java\sca\databinding\databinding-jaxb\target folder and post it to me? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 7:12 PM Subject: Re: Build error Hi Raymond, I am running mvn from /java. Here is my surefire repository stuff: Thanks, --Kevin Raymond Feng wrote: Hi, Kevin. I have exactly the same env as you. But I cannot reproduce the problem. Do you run the mvn from the root? Can you also check what version of surefire plugin you have in the local maven repo? Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 3:18 PM Subject: Re: Build error Hi Raymond, XP Maven version: 2.0.4 Java: C:\apacheSVN\javajava -version java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006050 4 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a Is there any other info you need? Thanks, --Kevin Raymond Feng wrote: Hi, Kevin. Can you give me more information on how to reproduce the problem (information about your env will be helpful as well since I don't see the problem) so that I debug it? I know the cause and I thought it was fixed by upgrading the surefire plugin. Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 24, 2006 12:14 PM Subject: Build error I brought this up awhile back and Raymond seemed to recognize the error. I don't think a fix or workaround was ever suggested suggested. [surefire] testTransformation2(org.apache.tuscany.databinding.TransformationTest Case) Time elapsed: 0.06 sec ERROR! java.lang.NoClassDefFoundError: com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLea fInfoImpl (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:123) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.init(RuntimeT ypeInfoSetImpl.java:25) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:78) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet( RuntimeModelBuilder.java:41) at com.sun.xml.bind.v2.model.impl.ModelBuilder.init(ModelBuilder.java: 97) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.init(RuntimeMode lBuilder.java:44) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContex tImpl.java:343) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.init(JAXBContextImpl.ja va:215) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 76) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 55) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java: 124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - 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] - 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: Avoiding extension and application scdl collisions
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]
