Bootstrap the tuscany system without dependency on SCDL and Java component
Hi, As part of the modulization efforts, I managed to put together a prototype to bootstrap Tuscany with hand-wired system components. It doesn't have dependency on the SCDL loading and Java component implementation. I was able to use it to run a simple CRUD component with an updated version of the embedd-host. The code is checked in at https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/rfeng/minicore. I would like bring it into trunk. Please let me know what you think. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question on ModelObject for binding extension
Hi, I read the article "Extending Tuscany by contributing a new implementation / binding type" by Raymond and Jeremy. Got a question about the definition of ModelObject. The example in the article is a very simple java bean-like object. This is fine if all we have to deal with is some simple attributes in the extension. If the binding requires complex SCDL model extension, defining the ModelObject by hand may not be the best choice (let's say one could have mulitple layers of nested elements and arrays etc.). One obvious alternative would be to generate some model code based on the extension xsd using EMF. However, since the binding's xsd extends from sca-core.xsd, generating model code would require the core model, which doesn't exist in Tuscany. What would be the recommended mechanism to define the ModelObject in this case? -pam
[jira] Updated: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1199: -- Attachment: AccountHistoryService.wsdl default.scdl > ClassCastException when getting back a type extended from anything besides a > string > --- > > Key: TUSCANY-1199 > URL: https://issues.apache.org/jira/browse/TUSCANY-1199 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Web App Runtime >Affects Versions: Java-M2 > Environment: Apache Tomcat 5.5.17 >Reporter: Sunny Ip > Attachments: AccountHistoryService.wsdl, default.scdl > > > Originally posted under SDO Implementation, but it was suggested it may be an > SCA proxy problem: > In my client code (originating from a JSP), whenever I am expecting a return > type that extends anything but a string (tried so far with boolean, int, > double, decimal, long), I get the following when I call my service: > java.lang.ClassCastException: java.lang.String > $Proxy34.getAccountBalance(Unknown Source) > com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) > > org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) > > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) > > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) > > Here is a snippet from a WSDL file that is being used: > http://sample"; targetNamespace="http://sample";> > > > > > > > > > > > > > > > > > > > > > with everything else exactly the same, changing the return type for > getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes > everything work fine. I have attached the wsdl and scdl (client side) files > for reference. To reproduce: > 1) create/generate classes to implement and consume the service described by > the wsdl > 2) expose the service in your scdl > 3) call the getAccountBalance operation > The crash will occur after the method on the service side is complete, but > before the client gets a response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1199 URL: https://issues.apache.org/jira/browse/TUSCANY-1199 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Runtime Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Originally posted under SDO Implementation, but it was suggested it may be an SCA proxy problem: In my client code (originating from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following when I call my service: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: http://sample"; targetNamespace="http://sample";> with everything else exactly the same, changing the return type for getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes everything work fine. I have attached the wsdl and scdl (client side) files for reference. To reproduce: 1) create/generate classes to implement and consume the service described by the wsdl 2) expose the service in your scdl 3) call the getAccountBalance operation The crash will occur after the method on the service side is complete, but before the client gets a response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
calling webservice using service interface only
Hi guys, How i can call a tuscany java web service using a service interface only. I don't want any tuscany related code inside client code CompositeContext compositeContext = CurrentCompositeContext.getContext(); compositeContext.locateService(service.class, "ServiceClientComponent"); inside client code. thanks, muhwas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486110 ] Frank Budinsky commented on TUSCANY-1198: - Another thought ... getting String values is often an indication that the metadata isn't available at runtime, so it could be that the SDO metadata hasn't been registered in the application's context. > ClassCastException when getting back a type extended from anything besides a > string > --- > > Key: TUSCANY-1198 > URL: https://issues.apache.org/jira/browse/TUSCANY-1198 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: Apache Tomcat 5.5.17 >Reporter: Sunny Ip > Attachments: AccountHistoryService.wsdl > > > In my client code (calling from a JSP), whenever I am expecting a return type > that extends anything but a string (tried so far with boolean, int, double, > decimal, long), I get the following: > java.lang.ClassCastException: java.lang.String > $Proxy34.getAccountBalance(Unknown Source) > > com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) > > org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) > Here is a snippet from a WSDL file that is being used: > http://sample"; targetNamespace="http://sample";> > > > > > > > > > > > > > > > > > > > > > with everything else exactly the same, changing the return type for > getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes > everything work fine. However, I need to be able to handle these kinds of > extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1198. - Resolution: Cannot Reproduce I generated the SDO interfaces using the attached wsdl file, and the getAccountBalanceResponse interface contains: double getReturn(); void setReturn(double value); Exactly the same as if xs:double was used as the type, instead of sample:Dollars. Since the SDO part is working as expected, perhaps this is some kind of SCA proxy problem? > ClassCastException when getting back a type extended from anything besides a > string > --- > > Key: TUSCANY-1198 > URL: https://issues.apache.org/jira/browse/TUSCANY-1198 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: Apache Tomcat 5.5.17 >Reporter: Sunny Ip > Attachments: AccountHistoryService.wsdl > > > In my client code (calling from a JSP), whenever I am expecting a return type > that extends anything but a string (tried so far with boolean, int, double, > decimal, long), I get the following: > java.lang.ClassCastException: java.lang.String > $Proxy34.getAccountBalance(Unknown Source) > > com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) > > org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) > Here is a snippet from a WSDL file that is being used: > http://sample"; targetNamespace="http://sample";> > > > > > > > > > > > > > > > > > > > > > with everything else exactly the same, changing the return type for > getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes > everything work fine. However, I need to be able to handle these kinds of > extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip updated TUSCANY-1198: -- Attachment: AccountHistoryService.wsdl > ClassCastException when getting back a type extended from anything besides a > string > --- > > Key: TUSCANY-1198 > URL: https://issues.apache.org/jira/browse/TUSCANY-1198 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-M2 > Environment: Apache Tomcat 5.5.17 >Reporter: Sunny Ip > Attachments: AccountHistoryService.wsdl > > > In my client code (calling from a JSP), whenever I am expecting a return type > that extends anything but a string (tried so far with boolean, int, double, > decimal, long), I get the following: > java.lang.ClassCastException: java.lang.String > $Proxy34.getAccountBalance(Unknown Source) > > com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) > > org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > > org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) > Here is a snippet from a WSDL file that is being used: > http://sample"; targetNamespace="http://sample";> > > > > > > > > > > > > > > > > > > > > > with everything else exactly the same, changing the return type for > getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes > everything work fine. However, I need to be able to handle these kinds of > extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1198) ClassCastException when getting back a type extended from anything besides a string
ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1198 URL: https://issues.apache.org/jira/browse/TUSCANY-1198 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip In my client code (calling from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: http://sample"; targetNamespace="http://sample";> with everything else exactly the same, changing the return type for getAccountBalanceResponse from "sample:Dollars" to "xsd:double" makes everything work fine. However, I need to be able to handle these kinds of extensions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved with EMF code)
Paul Golick <[EMAIL PROTECTED]> wrote on 04/02/2007 01:23:21 PM: [snip] > Is it accurate to categorize the code as "common to Apache Tuscany and to > Eclipse EMF"? or would you prefer a different description? We won't have exactly the same code in both projects. The two EMF classes, described below, are "code that IBM has contributed to both Eclipse EMF and Apache Tuscany". Thanks, Frank. [snip] > Frank Budinsky <[EMAIL PROTECTED]> > 2007-03-22 09:01 AM > Please respond to > tuscany-dev@ws.apache.org > > > To > tuscany-dev@ws.apache.org > cc > > Subject > Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 > > > > > > > Thank goodness, common sense applies :-) > > Now we can proceed with the release candidate. > > Thanks, > Frank. > > [EMAIL PROTECTED] wrote on 03/21/2007 05:27:35 PM: > > > On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > > > > > I've confirmed that IBM, the copyright holder, gives permission to > > > > Apache > > > > to reuse the two EMF files in question. > > > > > > Thanks for confirming this. > > > > > > > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > > > provided in > > > > an attachment. > > > > > > > > Jeremy, let me know if this is good enough for you, or if you still > > > > want > > > > me to remove the Tuscany subclasses and resubmit them. > > > > > > I can't ack this for the ASF - that has to be done by an Officer as > > > described in the IP Clearance process. They would probably want > > > something official from IBM (Software Grant). > > > > I am a director of the ASF. > > > > Apparently the original copyright holder desires to contribute the > > same code to two different places under two different licenses. They > > are certainly within their rights to do so. The contribution under > > the other license isn't particularly relevant to me. Now, concerning > > the contribution which is presumably being made in good faith under > > the ASF license to the Tuscany project, I see no ASF wide legal or > > policy issue here, which means that the only remaining issue a > > technical one, namely whether or not tuscany wishes to accept this > > code. > > > > Now, if anybody has any reason to believe that the assertion of > > authorship is false (i.e., if there are Eclipse CVS or SVN logs which > > show contributions by others), then the issue is an entirely different > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Next version - What should be in it
Hi, Here are a few things for consideration: 1) Databinding framework and a set of databinding extensions incuding SDO, JAXB, AXIOM and more 2) A refactored Java Container that handles Java component type 3) A refactored Tuscany Core without the dependency on Java Container 4) Refine the extensibility story for implementation/binding extensions Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Saturday, March 31, 2007 12:07 PM Subject: Re: [DISCUSS] Next version - What should be in it Jean-Sebastien Delfino wrote: ant elder wrote: On 3/30/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: Folks, Let's keep the ball rolling...Can someone please come up with a master list of "extensions, bindings, services, samples" which can then help decide what's going to get into the next release. Please start a wiki page to document the master list. Once we are done documenting the list. We can figure out which ones are MUST, which ones are nice to have, which ones are out of scope. Then we can work backwards to figure out How tightly or loosely coupled each piece is/should be and how we could decouple them if necessary using interfaces/spi/whatever... Quote from Bert Lamb: "I think there should be a voted upon core set of extensions, bindings, services, samples, whatever that should be part of a monolithic build." http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16062.html Quote from Ant Elder: The specifics of what extensions are included in this release is left out of this vote and can be decided in the release plan discussion. All this vote is saying is that all the modules that are to be included in this next release will have the same version and that a top level pom.xml will exist to enable building all those modules at once. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16155.html Thanks, dims I've created a minimal wiki page that so far just has a list of all the modules currently in java/sca: http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+next+release+planning I guess everything in contrib is not going to be in the next release unless something changes. How about also moving bpel, celtix and servicemix to contrib? Makes sense to me. I've not seen any activity in these modules recently, and they don't seem to build. If people are willing to work on them again and have them included in the next release, then it won't be a problem to move them back again. There's a few script containers now - groovy, javascript, ruby, bsf and jsr223 - I was planning on focusing just on the jsr223 container and hope to make it support everything the others do. So we could move all the others to contrib if no one is going to be working on them, but i don't see any problem with having a script language specific container as well as the jsr223 one if someone wants to work on one of those. +1 I think it is important to have support for scripting languages as they make it very easy to write the glue between the components in an SCA composite application. ...ant I'd like to add a list of samples. We have various samples in different places in the tree at the moment, I'll spend some time today sorting out that list and will update the wiki page with that today or tomorrow. Maybe it will help to add a one-line description of each module to indicate the main features that it provides? What do you think? I added to the Wiki page a table listing the samples we have, with a one line description of each. A few samples are still using old versions of SCDL and APIs but it shouldn't be too much work to port them to the latest spec level. I'd also like to have at some point a nice Web 2.0 sample similar to the AlertAggregator sample from the Tuscany SCA native project, but for that we'll need a REST binding (or maybe we can just start with JSON-RPC or the Axis2 support for REST) and more complete support for scripting components in the Java runtime. So I think that running AlertAggregator on the Java runtime will be much more work :) I'll spend more time going through the modules we currently have and add a short description of each to the Wiki. In addition to the list of modules, I think it would be good to have a high level list of features as well (like what subset of APIs are we going to support, what SCDL features, bindings, component implementation types, policies, which host environments, deployment tools etc.). Any thoughts? Could people start adding to the Wiki page or discuss in this thread what features they'd like to see? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using StAX-based loaders for SCDL? was: SCDL4J
+1. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Saturday, March 31, 2007 9:58 PM Subject: Using StAX-based loaders for SCDL? was: SCDL4J [snip] Raymond Feng wrote: Hi, FYI: I checked in the first cut of the StAX-based loaders under scdl4j/stax. The logic is very similar to the SAX handlers. Thanks, Raymond Thanks Raymond, your new StAX loaders look good to me! actually better than the SAX handlers that I had checked in yesterday :) I made a few minor changes to bring them to the same level of functionality as the SAX handlers, and then did a quick comparison between the two approaches. Performance: Here are some numbers from the SAXPerfTest and StAXPerfTest programs that I committed today, which load the same composite file using both techniques. - SAX handler using the JDK parser (Xerces): 0.395 msec - SAX handler using the Woodstox parser: 0.260 msec - StAX reader using the Woodstox parser: 0.258 msec Memory usage is slightly lower with StAX/Woodstox. So StAX/Woodstox wins by a very small margin, the bigger performance gain really comes from using Woodstox instead of the version of Xerces that comes with the JDK. Programming model: Both approaches are very similar. I think I slightly prefer Raymond's StAX-based approach as it allows state to be kept in local variables instead of instance variables shared by multiple event handling methods. Also, I thought that our core StAX loaders were a little fragmented before and that probably caused some of their complexity, but Raymond's new loaders now combines the simplicity of having the parsing logic in a single class (similar to the SAX handlers that I had contributed) and the convenience of the StAX pull parsing model. The other advantage of the StAX based approach is that it covers reading and writing XML documents (although it's easy to write code that produces SAX events to generate a document, as I did in CompositeWriter for example). Dependencies: The SAX based approach works with just a JRE and nothing else. StAX requires Woodstox (or another StAX implementation) or Java 6. To summarize, the StAX loaders are slightly faster, slightly simpler to write, but require Woodstox (about 500Kb). I'd like to remove the SAX handlers that I had contributed in favor of Raymond's new StAX loaders, but since one of the goals of this SCDL4J package is to make SCA really pervasive and allow projects to consume SCA metadata with minimum dependencies, I'd like to make sure that the Woodstox dependency is not going to be a problem for people. Other similar packages like WSDL4J or Woden for example only require the JRE... So, what do people think about this dependency on a StAX parser like Woodstox? If there's no objections I'll switch to use Raymond's StAX loaders around the end of the day on Monday... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 (IBMers involved with EMF code)
Frank, Were you the only IBM employee involved in the contribution of this code that is common to Apache Tuscany and to Eclipse EMF? If not, who were the other IBM employees? If it accurate to categorize the code as "common to Apache Tuscany and to Eclipse EMF"? or would you prefer a different description? This will answer a question for the "enhanced pedigree review" of the Tuscany code so that we can ship SOA Feature Pack Iteration 1. Regards, Paul Golick P. O. Box 12195, Dept. 6HSA (503 D224) 3039 Cornwallis Rd. Research Triangle Park, NC 27709-2195 office phone: 919-543-7177 cell phone: 919-943-2578 home phone: 919-493-3570 e-mail: [EMAIL PROTECTED] Frank Budinsky <[EMAIL PROTECTED]> 2007-03-22 09:01 AM Please respond to tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org cc Subject Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1 Thank goodness, common sense applies :-) Now we can proceed with the release candidate. Thanks, Frank. [EMAIL PROTECTED] wrote on 03/21/2007 05:27:35 PM: > On 3/21/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: > > > > > I've confirmed that IBM, the copyright holder, gives permission to > > > Apache > > > to reuse the two EMF files in question. > > > > Thanks for confirming this. > > > > > > > > I've opened TUSCANY-1185 to contribute the two base classes, > > > provided in > > > an attachment. > > > > > > Jeremy, let me know if this is good enough for you, or if you still > > > want > > > me to remove the Tuscany subclasses and resubmit them. > > > > I can't ack this for the ASF - that has to be done by an Officer as > > described in the IP Clearance process. They would probably want > > something official from IBM (Software Grant). > > I am a director of the ASF. > > Apparently the original copyright holder desires to contribute the > same code to two different places under two different licenses. They > are certainly within their rights to do so. The contribution under > the other license isn't particularly relevant to me. Now, concerning > the contribution which is presumably being made in good faith under > the ASF license to the Tuscany project, I see no ASF wide legal or > policy issue here, which means that the only remaining issue a > technical one, namely whether or not tuscany wishes to accept this > code. > > Now, if anybody has any reason to believe that the assertion of > authorship is false (i.e., if there are Eclipse CVS or SVN logs which > show contributions by others), then the issue is an entirely different > 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: Moving on
Hi, It's a pity. Best wishes to you all and good luck in the new project. Thanks, Raymond - Original Message - From: "Meeraj Kunnumpurath" <[EMAIL PROTECTED]> To: Sent: Monday, April 02, 2007 10:11 AM Subject: Re: Moving on Hi guys, Just want to send a quick note to say I have decided to move on. I would like to wish you guys all the best. Thanks Meeraj From: Jean-Sebastien Delfino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Moving on Date: Mon, 02 Apr 2007 09:33:27 -0700 Davanum Srinivas wrote: Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims Best of luck guys. I hope that the two projects can cooperate in the future. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail http://ideas.live.co.uk - 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: Moving on
Hi guys, Just want to send a quick note to say I have decided to move on. I would like to wish you guys all the best. Thanks Meeraj From: Jean-Sebastien Delfino <[EMAIL PROTECTED]> Reply-To: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org Subject: Re: Moving on Date: Mon, 02 Apr 2007 09:33:27 -0700 Davanum Srinivas wrote: Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims Best of luck guys. I hope that the two projects can cooperate in the future. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail is evolving - check out the new Windows Live Mail http://ideas.live.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deep introspection in JavaInterfaceProcessorRegistryImpl
Venkata Krishnan wrote: Hi, When promoting a component reference to the composite level, the specs says that if an interface is specified in the composite reference it must be a superset of what is specified for the component reference that is being promoted. To do this I reused the CheckCompatibility method in the 'WireServiceExtension'. But then this checking is done during the phase when a composite is being loaded and in this phase it seems like the JavaInterfaceProcessorRegistryImpl does not do a deep introspection of the JavaInterface of the component's reference (that is being promoted). As a result of this there seems to be no comparison possible. Any ideas on how I can get over this ? Thanks - Venkat One way to fix this (and a number of other related problems caused by premature) would be to split the loading of SCA metadata in multiple phases: 1. load the assembly model from .composite, .componentType and .constrainingType files 2. resolve referenced application artifacts (implementation classes and service interfaces for example), and introspect them 3. normalize the assembly model, connect includes to their parents, resolve wires, nested composites, check interface compatibility etc. What do you think? would that help? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Testcase failures in scdl4j
Hi, I'm seeing a few failures in the scdl4j modules: Tests in error: testBuildComposite(org.apache.tuscany.scdl.xml.BuildCompositeXMLTestCase) testWriteComponentType(org.apache.tuscany.scdl.WriteTestCase) testWriteComposite(org.apache.tuscany.scdl.WriteTestCase) testWriteConstrainingType(org.apache.tuscany.scdl.WriteTestCase) One of the stack trace is: javax.xml.transform.TransformerException: Can't transform a Source of type javax.xml.transform.sax.SAXSource at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:439) at org.apache.tuscany.scdl.xml.BuildCompositeXMLTestCase.testBuildComposite(BuildCompositeXMLTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I'm using IBM JDK 5.0 and it seems that the TrAX doesn't support such a transformation. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving on
Davanum Srinivas wrote: Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims Best of luck guys. I hope that the two projects can cooperate in the future. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
calling tuscany service using spring
Hi guys, How i can call a tuscany java web service using a simple java client. I mean no CompositeContext compositeContext = CurrentCompositeContext.getContext(); and compositeContext.locateService(service.class, "ServiceClientComponent"); inside client code. thanks, muhwas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1196) java.lang.ClassCastException org.eclipse.emf.ecore.impl.DynamicEObjectImpl incompatible with commonj.sdo.DataObject
[ https://issues.apache.org/jira/browse/TUSCANY-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1196. - Resolution: Fixed Fix Version/s: Java-SDO-M3 Fixed in revision 524792. > java.lang.ClassCastException org.eclipse.emf.ecore.impl.DynamicEObjectImpl > incompatible with commonj.sdo.DataObject > --- > > Key: TUSCANY-1196 > URL: https://issues.apache.org/jira/browse/TUSCANY-1196 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation >Affects Versions: Java-SDO-M3 > Environment: M3 release candidate 1. Modified version as described by > Frank Budinsky: > http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00754.html >Reporter: Christian Landbo Frederiksen > Fix For: Java-SDO-M3 > > Attachments: TestSDOErronousSchemaReferences.java > > > First reported here: > http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00758.html > When a schema with an invalid reference to another schema is defined it > causes an IllegalArgumentException. If the same helperContext is later used > to define another schema and then attempting to create using DataFactory > causes a ClassCastException - though nothing is wrong with the second schema > (passes define - create fails). > The attached JUnit testcase illustrates the problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving on
Best of luck guys. I could see the frustration on the list for a while. I trust your project will be wildly successful and perhaps given distance and time a better relationship will end up being the result for Tuscany and your project. On Mar 30, 2007, at 8:52 PM, Davanum Srinivas wrote: Team, FYI, Looks like Jeremy, Jim and Meeraj will be working on something new. http://code.google.com/p/fabric3/ Please wish them best of luck. thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - 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: Moving on
On 4/2/07, Bert Lamb <[EMAIL PROTECTED]> wrote: http://fabric3.googlecode.com/svn/README.txt Looks like it is a fork. Which is disappointing. My only hope is that this will help us get back on track to organizing Tuscany and building a community here. yep..i asked because i've read that. from that readme however, it seems like they'll work on the federated runtime, and not the whole thing... well..let's see. I'm sure they'll make a great job, and the projects will learn from each other and (hopefully) cooperate. -- http://valerioschiavoni.blogspot.com http://jroller.com/page/vschiavoni - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving on
Looks like it is a fork. Which is disappointing. I'm also disappointed --- I think that resolving arguments and finding technical ways to meet multiple competing needs is one of the strengths of open source. And forking is one of the weaknesses. But its just my 2c worth. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge improved databinding code into trunk
On 3/29/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi Raymond, Once you have done this, I'd like to get started with syncing up the trunk for complex and many valued properties since this depends on the databinding framework to trasform property definitions in SCDLs to JavaObejects. - Venkat On 3/28/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > I'll go ahead to commit the last piece which integrates the databinding > framework with the latest core if there are no other concerns. > > The new picture will be: > > kernel/core: will depend on databinding-framework (the dependency would be > removed as the core is further decomposed) > services/databinding/databinding-framework: Databinding SPIs and built-in > transformers for XML > kernel/databinding: Databinding related WirePostProcessors and Inteceptors > > Thanks, > Raymond > > - Original Message - > From: "Raymond Feng" <[EMAIL PROTECTED]> > To: > Sent: Friday, March 16, 2007 10:38 PM > Subject: Merge improved databinding code into trunk > > > > Hi, > > > > As you might have noticed on the ML, I have improved the databinding > code > > in the sca-java-integration branch over time. I would like to merge the > > changes back to the trunk and bring up the databinding support again in > > the trunk. > > > > Here is the summary of the improvements: > > > > 1. Minimize the usage of @DataType by agressively introspecting the java > > classes > > > > 2. Data transformation for business exceptions > > > > 3. Add copy() support for JAXB and AXIOM > > > > 4. More databindings and transformers such as: > > * JSON databinding > > * SDO --> AXIOM using OMDataSource > > * JavaBean --> XMLStreamReader > > > > 5. More unit and integration test cases for better coverage > > > > To avoid the disruption, I'll stage them as follows: > > 1) Add a "databinding-framework" module under > > "java/sca/services/databinding" to hold the updated code in spi and > core. > > 2) Update individual databindings > > 3) Integrate the databinding pieces with the latest core > > > > Thanks, > > Raymond > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Hi I'm now in the process of copying the Databindings itest from the integration branch to the trunk. I've copied tests for only a few simple types but it doesn't work yet as there are problems with the axis extension (WorkContexT param missing from some method signatures). Once extension problems are ironed out we can back fill with more complex type testing, transformer tests etc. I don't have much time this week so will move it along as and when I can grab 5 mins. It's not plumbed into the higher level itest pom yet so it shouldn't break anything. Regards Simon
[jira] Commented: (TUSCANY-1184) Extend depth and breath of generated databinding tests
[ https://issues.apache.org/jira/browse/TUSCANY-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485956 ] Simon Laws commented on TUSCANY-1184: - The tests, as they stand, are now copied into the trunk. They still need work to broaded the databindings that are tested and the types that are used during the tests. > Extend depth and breath of generated databinding tests > -- > > Key: TUSCANY-1184 > URL: https://issues.apache.org/jira/browse/TUSCANY-1184 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Integration Tests >Affects Versions: Java-SCA-integration > Environment: All supported >Reporter: Simon Laws > Assigned To: Simon Laws >Priority: Minor > > The tests as originally commited provided hard coded suport for a limited > number of types in SDO and JAXB bindings. These hard coded tests have been > augmented with a common project to store shared schema and a set of template > files that can be used to generate the tests themselves. The work now is to > fill out the set of types and combinations of bindings tested. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
