[jira] Assigned: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ] ant elder reassigned TUSCANY-61: Assign To: ant elder ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: ant elder Assignee: ant elder Priority: Minor Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-61) ?WSDL on WS binding entryPoints fails
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ] ant elder closed TUSCANY-61: Resolution: Fixed Applied patch ?WSDL on WS binding entryPoints fails - Key: TUSCANY-61 URL: http://issues.apache.org/jira/browse/TUSCANY-61 Project: Tuscany Type: Bug Components: Java SCA Axis Integration Reporter: ant elder Assignee: ant elder Priority: Minor Appending ?WSDL to the url of a entryPoint with a WS binding should return the WSDL, but it fails, first as its missing the xmlschema jar then once thats available with the following exception. Looks like its trying to gen a new wsdl but it should be able to use the definition from the model. org.apache.axis2.AxisFault: no scheam found for the service; nested exception is: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:373) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:322) at org.apache.axis2.transport.http.ListingAgent.listService(ListingAgent.java:469) at org.apache.axis2.transport.http.ListingAgent.handle(ListingAgent.java:393) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doGet(WebServiceEntryPointServlet.java:140) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.Exception: no scheam found for the service at org.apache.axis2.description.AxisService2WOM.generateWOM(AxisService2WOM.java:86) at org.apache.axis2.description.AxisService.printUsingWOM(AxisService.java:362) ... 20 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-120) Axis2 WS binding support for entryPoint without pre-existing WSDL
Axis2 WS binding support for entryPoint without pre-existing WSDL -- Key: TUSCANY-120 URL: http://issues.apache.org/jira/browse/TUSCANY-120 Project: Tuscany Type: Improvement Components: Java SCA Axis Integration Reporter: ant elder Priority: Minor Where the entryPoint doesn't use interface.wsdl then the pre-existing WSDL document shouldn't be required. Axis2 can generate WSDL at runtime based on the service interface so the Axis2 binding can use that to support the following: entryPoint name=AccountService interface.java interface=org.apache.tuscany.binding.axis2.assembly.tests.bigbank.account.services.account.AccountService/ binding.ws/ referenceAccountServiceComponent/reference /entryPoint See ML discussion: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200603.mbox/[EMAIL PROTECTED] -- 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
Creating a new binding
When tuscany was dropped in svn, I had written a new binding for ServiceMix. I'm in the process of updating to latest tuscany svn head but it seems lots of things have changed. I'm basing the new code on the axis2 binding, but the problem i 'm facing is my binding.jbi element is not recognized by the SCDL loader. I guess I need to write an xsd and generate or manually write the new classes in the org.apache.tuscany.model package, but I have no found a way to make them recognized by the parser. How can I accomplish that ? Cheers, Guillaume Nodet
Re: Creating a new binding
I believe they based the integration on what was there prior to the introduction of the new core architecture, including aggregates and builders. If I recall correctly, TuscanyModuleComponentContextImpl was used, which no longer exists. The best place to start may be to look at some of the bindings and implementation types. There is an Axis2 binding and JSON binding as well as the Java and JavaScript types. A couple of caveats, though: - Changing the loaders to a StAX-based solution is under discussion - Some of the bindings use a deprecated API, getAggregate(), that is going to be removed - There will likely be some more churn in the core, although hopefully not to the extent that has been taking place I need to do documentation on how parts of the extension model works...in the meantime, I'm happy to help as well answering any questions. Jim On Mar 15, 2006, at 3:55 AM, ant elder wrote: If you're code is available somewhere I'd be happy to have a look for what you're missing. At a guess, do you have a static initializer registering the SCDL factory? If you've based your code on the Axis binding then you probably wont as its built into the Tuscany core so doesn't need one, same for the Java container. For one that works see: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/ binding.jsonrpc/src/main/java/org/apache/tuscany/binding/jsonrpc/ loader/JSONRPCSCDLModelLoader.java ...ant On 3/15/06, Guillaume Nodet [EMAIL PROTECTED] wrote: When tuscany was dropped in svn, I had written a new binding for ServiceMix. I'm in the process of updating to latest tuscany svn head but it seems lots of things have changed. I'm basing the new code on the axis2 binding, but the problem i 'm facing is my binding.jbi element is not recognized by the SCDL loader. I guess I need to write an xsd and generate or manually write the new classes in the org.apache.tuscany.model package, but I have no found a way to make them recognized by the parser. How can I accomplish that ? Cheers, Guillaume Nodet
[RESULT] Remove old contrib directory?
Jeremy Boynes wrote: This directory contains the seed code from BEA and IBM. Things have moved on quite a bit since then so I would like to suggest we remove this code from the tree - old versions can still be found in the SVN history if needed. This tree has been modified so no longer represents the original contribution anyway. I think this is worth voting on so I would suggest we need at least three +1's and no -1's before doing it. +1 from Jeremy Boynes, Jim Marino, Mike Edwards, Ant Elder, Rick Rineholt with comments about saving the code templates no -1 or other votes I will remove this tree later this week once I have had a chance to move the code templates to the website. -- Jeremy
Re: Creating a new binding
Guillaume Nodet wrote: Thanks, that was exactly what I was looking for. I bet the line SDOUtil.registerStaticTypes(ScdlFactory.class); will save me :) The code is available at http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-sca/ but as Jim just said, it is based on code that is more than 2 months old and it seems I need to rewrite it completely. Would it be easier to move this over to Tuscany? If this is a JBI binding that allowed Tuscany to run in any JBI container then it would have general applicability and by bringing it over we can help maintain it as things change (given Tuscany's fairly volatile). Would it be possible to handle this like our Tomcat integration where in one case we have a generic J2EE mode which works with any web container and in another we have a deep integration to Tomcat internals which provides simpler configuration for users? -- Jeremy PS if you're not aware, we're currently discussing whether to stick with this SDO based config loader or switch to a different one - it might be worth hanging on a couple days or jumping in that discussion
promotion of projects to the core
Hi, I wanted to raise the issue of how projects are promoted to the core set of projects in the Java SCA runtime. IMO adding a project to java/sca is a commitment by the community for long-term support. Because of this, I would like to propose that prior to promoting a project to java/sca we discuss and vote on the list. Any promoted project should also meet some minimum (and hopefully not onerous) requirements, such as test case coverage. Can we follow this process for the JSON binding? On a related note, I would like to keep the number of core bindings and implementation types limited. I am concerned we are adding a bunch of new things without completing proper test coverage for existing projects and introducing new dependencies. To help manage the introduction of new bindings and implementation types, I propose we create a better structuring than what we have now. Under java/sca we should keep java.container and move additional implementation types to another area, perhaps an implementation type project hierarchy with sub projects for supported implementation types. For bindings, we would keep axis2 under java/ sca but put additional supported bindings under a binding type project hierarchy. I'm interested in keeping the core runtime simple, limiting dependencies, and including only those things we as a community decide to support long-term. Thoughts? Jim
Re: Word docs
I really would like to make a distinction here between source form documents and final form documents. I agree that anything placed on the website as a final form document should be in a generally acceptable open form. HTML, Maven Xdoc, PDF, for example. Word documents are NOT acceptable as final form. Source form documents are a different issue in my opinion. These should be in a form that permits straightforward editing. For longer documents, formats like Word or OpenOffice seem reasonable, since you need the capability of good editing software to handle these documents. I don't think that formats like these should be outlawed for source form. I don't regard Maven xdoc as a good source form for longer documents since there is no tooling that I have discovered that helps edit them other than a simple text editor. DITA requires tooling to help - and my contacts in the IBM ID department indicate that DITA tools are complex and require education. HTML is OK-ish as a source form. There are at least some good open source tools to help edit it. Plain text simply doesn't look good for longer documents - and loses useful capabilities like hyperlinks. Yours, Mike.
ModuleScopeContext.start lifecycleState ?
Looking through parts of the code and I notice ModuleScopeContext.start() does not set lifecycleState to RUNNING Have notice no issues with it, just curious it doesn't. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ModuleScopeContext.start lifecycleState ?
Yes, RUNNING is set when the module scope event starts (see onEvent (int type, Object key) ). This may be a bit confusing, in which case we could change the name. Jim On Mar 15, 2006, at 10:04 AM, rick rineholt wrote: Looking through parts of the code and I notice ModuleScopeContext.start() does not set lifecycleState to RUNNING Have notice no issues with it, just curious it doesn't. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: ModuleScopeContext.start lifecycleState ?
Thanks Jim, Maybe a comment would suffice? Tough to pick up. Jim Marino wrote: Yes, RUNNING is set when the module scope event starts (see onEvent(int type, Object key) ). This may be a bit confusing, in which case we could change the name. Jim On Mar 15, 2006, at 10:04 AM, rick rineholt wrote: Looking through parts of the code and I notice ModuleScopeContext.start() does not set lifecycleState to RUNNING Have notice no issues with it, just curious it doesn't. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Word docs
Mike Edwards wrote: I really would like to make a distinction here between source form documents and final form documents. I agree that anything placed on the website as a final form document should be in a generally acceptable open form. HTML, Maven Xdoc, PDF, for example. Word documents are NOT acceptable as final form. I agree. I think the biggest thing that determines final form should be how people will read these documents: html is good for online use, pdf is good for offline/printing. It may be appropriate to publish the same information in different forms if people use it differently. Source form documents are a different issue in my opinion. These should be in a form that permits straightforward editing. For longer documents, formats like Word or OpenOffice seem reasonable, since you need the capability of good editing software to handle these documents. I don't think that formats like these should be outlawed for source form. I think we need to be careful about the accessibility of these formats to authors. As an author you want an easy editing experience; however, you also want other people in the community to be able to assist with/contribute to that editing process. An important factor here is how high the barrier to entry is for other people in the community who wish to join in this editing process. For example, MS-Word is prevalent in the Western commercial world; in other parts of the world it may not be so accessible. Think also about how other people can contribute modifications to the source documents. It is easy to review a patch to a simple text file but very hard to do for a binary document or one generated from some tool. I don't regard Maven xdoc as a good source form for longer documents since there is no tooling that I have discovered that helps edit them other than a simple text editor. DITA requires tooling to help - and my contacts in the IBM ID department indicate that DITA tools are complex and require education. HTML is OK-ish as a source form. There are at least some good open source tools to help edit it. Plain text simply doesn't look good for longer documents - and loses useful capabilities like hyperlinks. When you look around other Apache projects you see a variety of formats used but most come down to fairly simple text-based files. Developers here tend to be lazy^H^H^H take path of least resistance when it comes to documentation. That they tend to stick with hard to edit but open forms says something; in the end having someone else help keep the document up to date is easier than doing it all yourself :-) -- Jeremy
Data flow on a wire
A couple of us had an offline chat about what the format of data would be exchanged on the wire during an interaction between a client and a provider. The spur for this was the JSON binding Ant was working on which has no obvious affinity to XML. Another issue related to this has been about supporting streaming types for interactions where data flows through a system rather than terminating there. This is related to Axiom and its use for precisely this purpose in Axis2. I wanted to capture thoughts whilst still current and open the discussion. As I see it there is no single answer to this, well apart from it depends. :-) I think it is necessary for us to support the flow of any data type that is supported by both the client and the provider. With the ability to attach data transformation mediations to wires, this actually becomes a requirement to support any data type that can be mapped from client to provider and back again. In any interchange there are just two things that are defined: the format of data that will be supplied by the client and the format of data that will be consumed (delivered to) the provider. Neither client or provider needs to be aware of the format of data on the other end or of what gyrations the fabric went though in order to make the connection. As part of making the connection, it is the fabric's job to make the connection as efficient as possible, factoring in the semantic meaning of the data, the policies that need to be applied, and what the different containers support. All this flexibility just about requires we use the most generic type possible to hold the data being exchanged: a java.lang.Object or a (void*) depending on the runtime. The actual instance used would depend on the actual wire, some examples from Java land being: * POJO (for local pass by reference) * SDO (when supplied by the application) * Axiom OMElement (for the Axis2 binding) * StAX XMLStreamReader (for streamed access to a XML infoset) * ObjectInputStream (for cross-classloader serialization) and so forth. Each container and transport binding just needs to declare which data formats it can support for each endpoint it manages. The wiring framework need to know about these formats and about what transformations can be engaged in the wire pipeline. For example, the Axis2 transport may declare that it can support Axiom and StAX for a certain port and the Java container may declare that it can only handle SDOs for an implementation that expects to be passed a DataObject. The wiring framework can resolve this by adding a StAX-SDO transform into the pipeline. The limitation here is whether a transformation can be constructed to match the formats on either end. If one exists then great, but as the number increases then developing n-squared transforms becomes impractical. A better approach would be to pick the most common formats and require bindings and containers to support those at a minimum, with other point-to-point transforms being added as warranted. Given the flow issue descibed above and the XML nature of many our interactions I would suggest that a StAX XMLStreamReader may be the most apporpriate common format (at least for now). It's native to Axis2 and Raymond has posted patches already to support it in SDO. Alternatively, we don't need all of StAX for this to work so it may be simpler to provide a basic API that is essentially the same as an XMLStreamReader but without all the other stuff. Thanks for reading this far. The idea was to capture thinking and all input is welcome. -- Jeremy
Re: Data flow on a wire
On Mar 15, 2006, at 3:37 PM, Jeremy Boynes wrote: A couple of us had an offline chat about what the format of data would be exchanged on the wire during an interaction between a client and a provider. The spur for this was the JSON binding Ant was working on which has no obvious affinity to XML. Another issue related to this has been about supporting streaming types for interactions where data flows through a system rather than terminating there. This is related to Axiom and its use for precisely this purpose in Axis2. I wanted to capture thoughts whilst still current and open the discussion. As I see it there is no single answer to this, well apart from it depends. :-) I think it is necessary for us to support the flow of any data type that is supported by both the client and the provider. With the ability to attach data transformation mediations to wires, this actually becomes a requirement to support any data type that can be mapped from client to provider and back again. In any interchange there are just two things that are defined: the format of data that will be supplied by the client and the format of data that will be consumed (delivered to) the provider. Neither client or provider needs to be aware of the format of data on the other end or of what gyrations the fabric went though in order to make the connection. As part of making the connection, it is the fabric's job to make the connection as efficient as possible, factoring in the semantic meaning of the data, the policies that need to be applied, and what the different containers support. All this flexibility just about requires we use the most generic type possible to hold the data being exchanged: a java.lang.Object or a (void*) depending on the runtime. The actual instance used would depend on the actual wire, some examples from Java land being: * POJO (for local pass by reference) * SDO (when supplied by the application) * Axiom OMElement (for the Axis2 binding) * StAX XMLStreamReader (for streamed access to a XML infoset) * ObjectInputStream (for cross-classloader serialization) and so forth. Each container and transport binding just needs to declare which data formats it can support for each endpoint it manages. The wiring framework need to know about these formats and about what transformations can be engaged in the wire pipeline. For example, the Axis2 transport may declare that it can support Axiom and StAX for a certain port and the Java container may declare that it can only handle SDOs for an implementation that expects to be passed a DataObject. The wiring framework can resolve this by adding a StAX- SDO transform into the pipeline. The limitation here is whether a transformation can be constructed to match the formats on either end. If one exists then great, but as the number increases then developing n-squared transforms becomes impractical. A better approach would be to pick the most common formats and require bindings and containers to support those at a minimum, with other point-to-point transforms being added as warranted. This seems kind of like JBI. A question here is whether a normalized form is really practical and whether it is the easiest thing to do. Also, is mediation even the concern of the runtime? Should the runtime just make it possible to do mediation and delegate to a mediator interceptor/handler or create an implementation type that is a mediation component? Also, what about local invoke? I assume a container would have to declare support of primitives and Object? I think it may just be easier to settle on Object as the common form. Given the flow issue descibed above and the XML nature of many our interactions I would suggest that a StAX XMLStreamReader may be the most apporpriate common format (at least for now). It's native to Axis2 and Raymond has posted patches already to support it in SDO. Again, what about local invocations or things that just require simple serialization over a socket? Alternatively, we don't need all of StAX for this to work so it may be simpler to provide a basic API that is essentially the same as an XMLStreamReader but without all the other stuff. Thanks for reading this far. The idea was to capture thinking and all input is welcome. -- Jeremy
Re: Autowire algorithm
Jeremy did you start this or do you want me to do it? Jim On Mar 8, 2006, at 1:53 PM, Jeremy Boynes wrote: I'm not quite sure what the autowire algorithm is but the best I've figured out is: * The root RuntimeContext autowires to itself for services it provides and if not found delegates to the root system context * A SystemAggregateContext autowires to itself for services it provides or to SystemEntryPointContexts it immediately contains * A regular AggregateContext autowires to itself and to entry points it contains. If not found, it delegates to its parent As a result, autowires from application contexts propogate up the aggregate tree until they hit the runtime at the root which then delgates to the top-level system context. I'd like to propose a change to this algorithm to simplify the addition of system components as follows: * A component can request autowire to a service * The component's context delegates to its parent aggregate * A aggregate resolves autowire requests from contained children against any immediately contained child (EP, Component or ES) * If it cannot resolve the autowire, it delegates to its parent which will in turn attempt to resolve the autowire * This continues up to the roor where it stops because the root has no parent This is perhaps best illustrated with an example :-) Suppose I have the following tree of contexts: tuscany.runtime | + tuscany.system | | | + system1 | | | | | + system1a | | | + system2 | + tuscany.root | + app1 | + app1a | + app1b Suppose component app1a requests autowire to a service exposed as an entry point by tuscany.system. It passes this request to app1 which looks to see if the service is provided by any of its immediate children (app1a and app1b). It does not find any so delegates the request to tuscany.root. Again it is not resolved so the request is delegated to tuscany.runtime. tuscany.runtime sees that the service is provided by an entry point on its child tuscany.system and so that is the used as the target. If the service was instead just a component in tuscany.system, it would not be exposed as an entry point and hence tuscany.runtime would not resolved to it. Now suppose that component app1a requests autowire to a service that is provided by app1b. app1 would immediately resolve this to app1b. This supports autowire between components with the same parent. Finally, support component system1a requests autowire to a service exposed by system2. It would request resolution from system1 which would delegate to tuscany.system which in turn would resolve it to system. From a user's perspective, autowire would work as follows: * it would resolve to components in the same module * it would resolve to components in any parent module * it would resolve to entry points exposed by siblings or siblings of parents (uncles?) * it would not resolve to components contained by siblings or children Doing this results in one autowire algorithm across the whole system and eliminates the special-case behaviour in RuntimeContextImpl and SystemAggregateContextImpl. Comments welcome and if no-one has issues I will start to implement this later this week. -- Jeremy
Re: Autowire algorithm
Jim Marino wrote: Jeremy did you start this or do you want me to do it? I have not started yet - if you have time that would be great. -- Jeremy
