Graduation: PPMC Diversity
Folks, I've split this off as its a specific action item for Graduation. Based on Ant's comment: - the PPMC doesn't yet reflect the diversity of the committers. We've all been a bit busy with 1.0 etc and there's a few people now who we could look at as PPMC members, Matthieu brought this up earlier on the thread. Doing this now may help prevent any questions about diversity. OK, so I've added a to-do item into the Graduation Checklist here: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Graduation+Checklist ...but the debate is going to have to take place on the Tuscany Private list, right? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Folks, My pennyworth: a Project Management Committee charged with the creation and maintenance of open-source software supporting a range of technologies that simplifies the development of service oriented applications and provides a managed service-oriented runtime, based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. I think it worth pointing out that there will be support for a range of technologies - both implementation kinds and protocol kinds -hence the words I've added. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Folks, Simon Laws wrote: On 9/27/07, ant elder <[EMAIL PROTECTED]> wrote: On 9/27/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: So you have 4 more days after Sunday :) But there's no reason to rush out, I'm just clarifying the timeline, you'll be ready when you'll be ready and you can also target Nov. 21st. The November time frame sounds good to me and gives plenty of time to sort out things and bring it up with the IPMC so we know if they've any issues we need to address before calling a vote. I think that November is allowing things to slide too much. Are there any reasons that will DEFINITELY prevent achieving October? Otherwise October is my vote. ...ant But there is nothing stopping us pushing ahead now. If we happened to be ready for October we should try for October. +1 from me. Leaving a slacker schedule typically does not help. Set the challenging schedule and focus on the big items to get us there. Go for October. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA JAXB related query...
Sudeep, Thanks for your query. Which non-SCA runtimes are you describing here? And which IDE? SCA is not itself an IDE - are you expecting the necessary support classes to be generated on-the-fly by the SCA runtime? Yours, Mike. Sudeep Mallick wrote: Hi, I have a minor query on SCA using JAXB binding. How do I pass around custom data type for example, a PurchaseOrder class while having SCA domain client and server interaction. I have tried the same code for non-SCA Web services based service provider and consumer and it works primarily the support classes for unmarshalling/marshalling get generated by the IDE. However, for the case of SCA no such support classes are generated. I was assuming SCA runtime would take care of it, but it doesnt. What should I do? Any pointers to any guide, etc would also help. Thanks, Sudeep - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NOTICE] Simon Nash voted as Tuscany Committer.
Folks, The Tuscany PPMC and the Incubator PMC have voted for Simon to become a Tuscany committer. Congratulations and welcome Simon! I'm sure that everyone will be looking forward to more excellent contributions from Simon to Tuscany. Yours, Mike.
Re: Optimize the reference injection for java components
Folks, Comments inline Mike. Simon Nash wrote: By changing the lifecycle of the target instance I mean that it would be created eagerly (on source reference creation) rather than lazily (on source reference invocation) as is done currently. From looking at the new code I believe this is what would happen. (If I have misunderstood, please correct me.) An example of the difference is that if a conversational scoped component A references a stateless scoped component B and invokes it ten times through the same reference within the same conversation, at present we would create ten copies of B, one per invocation. With this new code, we would create one copy of B at the time that the A instance is created. This changes the lifecycle of B. It is arguably a change for the better, but it is still a change. My concern is whether the existing code has some deep-rooted dependence on the lifecycle of component instances. This may well become a problem over time. Now consider a stateless instance with references to other stateless components. For a long chain of references and services (A -> B -> C -> D -> E -> F), all six objects would be created at the same time when the A instance is created, rather than just creating the A instance and a proxy for B. Depending on the execution path through A, it's possible that five of these six objects will never be used. This doesn't seem good to me. I'm not surprised that our tests don't pick this up, because it isn't easy to test for this kind of thing. However, it can cause resource and performance issues in a real-world environment because of an excessive number of object creations and garbage collection cycles. This is a good point and it emphasises that optimisation must be looked at "in the large". Object pooling is one technique that is used in servers to deal with the problem of excessive creation of objects. It applies even if objects are only created "on demand" since if a new object is created for each method invocation, that can mean a huge heap of objects too. I note that the use of proxies actually creates double the number of objects - one proxy and one target for each invocation... One way to get the best of both worlds could be to inject a proxy initially and replace it with a direct instance pointer when the proxy is first invoked. This will need more code than the current proposed approach, but I think it may be worth doing for the efficiency benefits. Ideally we would prototype different approaches to see which one yields the best tradeoff in terms of overall execution efficiency and resource consumption. We don't have time to do this before the 1.0 release. I agree with the sentiment that this needs more time. Optimisation is no easy trick. Unless there is some big performance problem right now,it can be safely left for future work. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimize the reference injection for java components
Folks, Comments inline... Raymond Feng wrote: Even for the stateless case, I would argue it's legal to do the optimization. The SCA java spec says: "283 1.2.4.1. Stateless scope 284 For stateless components, there is no implied correlation between service requests." You've picked the right spec lines I think it should also be valid to get the same instances for multiple requests. For JEE stateless sessions, the container usally maintains an instance pool and pick the instance from pool as needed. So there is only one request at a time, then there is a good chance that the same instance is picked. Yes, there is no guarantee that you will get a DIFFERENT instance each time. The only point that is emphasised is that the implementer cannot rely on getting the SAME instance for each subsequent request. If the implementer stores some state then that state could be over the hills & far away when the next request arrives. My understanding of "stateless" is that there is no garauntee that multiple requests will be routed to the same instance. +1, absolutely Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimize the reference injection for java components
Simon, Some comments inline Simon Nash wrote: If I understand this correctly, it would affect the lifecycle of the target component instance. So when A has a reference to B, the creation of A currently involves creating and injecting a B proxy but not a B instance. With this change, I think the creation of A would involve creating a B instance and injecting a reference to this B instance into A. And if B references C, this would in turn involve creating a C instance and injecting its reference into B (and so on). I think there could be many consequences of this change, some of which may not be desirable. Creation on first invocation is easy to understand and consistent, and I'd be concerned about changing this. But creation can occur at other times. Scope controls this - COMPOSITE scope implies creation at deployment time, for example. So you need to be able to deal with these cases anyway. Creation on first invocation sounds like only one possible behaviour that must be handled. A related consideration is some of the callback cases that currently don't quite work as I would expect, because injection can only happen when an instance is created. I think there may be cases where we should be injecting/binding a callback reference when the forward call is received and disptached to an instance that already exists, and I'm working on a use case description for this. With Raymond's proposal, I think that the instances involved in the call & callback are well known "in advance" and it should work properly. Perhaps I'm wrong - and certainly it isn't the way it works today, but it could be made to work that way. I would prefer to defer this change until after 1.0 so that we can discuss it more fully to consider all the implications, and coordinate it with resolving the callback issues if we agree that a change is needed there. That's a fair point and I tend to agree, since this is an optimisation, not some fundamental function. I suspect it will take quite a piece of work to make it run properly in all scenarios. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optimize the reference injection for java components
Raymond, Raymond Feng wrote: Hi, We use either JDK or CGLib proxies in reference injections for java components. It is a bit heavy and unnecessary for some cases. I now add a simple optimization to inject the implementation instance directly if the following criteria are met: 1) Both the source and target are java components 2) The binding is local SCA binding 3) The target implementation class implements/extends the source interface/class 4) The target component scope is either STATELESS or COMPOSITE 5) There is only one invoker (JavaImplementationInvoker) in each invocation chain for all the operations What do you think? Thanks, Raymond This kind of optimisation has always been part of the idea behind SCA, so in general, I think this is fine. There are probably a lot of wrinkles (Simon's note mentions some) and I suggest that this should be prototyped and checked out before going into the mainline code. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to create composite diagrams for the samples
Folks, What about the latest stuff in Eclipse STP project? Yours, Mike. Jean-Sebastien Delfino wrote: I'd like to understand how to create composite diagrams similar to the ones Simon already created for most samples. Do we have a quick summary of the steps to do this? Is there a set of predefined shapes uploaded somewhere that we all can use for these diagrams? Should I use a tool like inkscape to create the diagrams? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation
Folks, +1. +1. Can we start to identify work tasks to get us there and then start to parcel out work amongst folk on the project? Yours, Mike. ant elder wrote: So how about trying to graduate Tuscany from the Incubator? :-) We seem close though there are a few things to sort out so it will take a couple of months to get ready. There's a draft proposal at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution, we probably need to work on the description which is just taken from the website home page: "open-source software related to infrastructure that simplifies the development of service-based application networks and addresses real business problems posed in SOA". We also need a bit more diversity in the initial PMC members listed in the proposal which is all our current PPMC members. I'd like to volunteer to be chair. There is a graduation guide at http://incubator.apache.org/guides/graduation.html. ..ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the SCA spec XSDs in the Tuscany distribution?
Folks, ant elder wrote: It would be interesting to know if the license will be changed to something more standard with the move to OASIS. The license will change, for sure, since OASIS has its own rules about these things. What exactly it will look like is one of the chores that I will have to deal with soon However, that change won't be for a while, since the OASIS TCs will have to approve publication of an OASIS version of the spec and the other artifacts. So don't hold your breath. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: uri of binding.ws should be used restrictedly
Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins "silently" in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder <[EMAIL PROTECTED]> Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng <[EMAIL PROTECTED]> wrote: Hello every one, uri attribute of is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. "WSDL becomes delicate" - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use "wsdlElement" will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using "#wsdl.port") in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
Folks, +1 from me Mike. Jean-Sebastien Delfino wrote: Hi, I'm thinking that we should include the XQuery implementation that Vasil has contributed in our next release as I think that XQuery gives us a great way to work with / mediate / transform XML data sources. To get ready for that and help Tuscany users understand what they can do with XQuery, I'd like to suggest the following improvements and simplifications to the XQuery sample at [1]. - Move the .xq files from src/main/resources/META-INF/sca to src/main/resources/xquery so that they are in plain sight and people realize that they are first class development artifacts; - support WSDL interfaces, basically removing the requirement to generate SDOs and write many Java interfaces, to help show that you can something useful with just XQuery without having to write any Java code; - I'm not sure about this one, but I was also thinking that we could simplify the sample by using local components instead of having a client + a server and web services in the middle... the idea is that a simpler example will be more effective at demonstrating the value of XQuery. In a parallel thread I'd like to start discussing how we could show XQuery components in the tutorial that we are preparing for ApacheCon 2007, for example to extract data out of the Amazon Web Services that we're planning to use in the tutorial. Thoughts? [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/quote-xquery/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCA Specifications starting up in OASIS
Folks, The SCA specifications which are implemented by Tuscany have just started out a new phase - they are moving to OASIS for formal standardization. This is being done as a series of OASIS technical committees, each dealing with one or more of the SCA specifications. The OASIS activities are carried out in public and it is possible to either observe activities in the various technical committees, or you are welcome to join one or more of the committees. You can find the 6 SCA technical committees here: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-policy http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-bindings http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-j http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-c-cpp http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-bpel Meeting minutes, documents, issues and so on are linked from the main page. Mailing list archives can be found here: http://www.oasis-open.org/archives/sca-assembly/ http://www.oasis-open.org/archives/sca-policy/ http://www.oasis-open.org/archives/sca-bindings/ http://www.oasis-open.org/archives/sca-j/ http://www.oasis-open.org/archives/sca-c-cpp/ http://www.oasis-open.org/archives/sca-bpel/ Please note that there is an SCA Plenary session taking place on Tuesday 18th September in Palo Alto, CA. This session is an education session about SCA and the work that will take place within OASIS over the next year or so. This session is free and open to anyone who registers for the session. For more details, please look here: http://www.oasis-opencsa.org/2007-09-18-program Yours, Mike Edwards. Co-Chair, OASIS SCA Assembly TC. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding unnecessary pass-by-value copies
Ant, ant elder wrote: I'm looking at what we could do for TUSCANY-1559 which is about unnecessary pass-by-value copies causing failures when arguments aren't serializable. The problem is on line 260 of JavaComponentContextProvider where it tries to determine if the pass-by-value invoker is required, but it doesn't take into account whats at the other end of the invocation chain. I'm a bit confused by this. These statements seem to imply that you can't use the service/reference in the case where remoting is going on. That will indeed be the case if you have non-serializable arguments. But why is the invocation chain of any relevance here? Or have I got the wrong end of the stick. Any service or reference that is remotable must have an interface that can be serialized onto a wire. SCA expresses this in terms of mappability to WSDL. If it's remotable it must be expressible in WSDL and serialization is part of this picture. How about changing this so its not the Java implementation types responsibility to handle pass-by-value and move it out into core, having a separate RuntimeWireProcessor and Interceptor for pass-by-value support, and don't do copies if the source and target interfaces use different databindings? ...ant Different databindings surely is not part of the problem. Again, you can map into and out of a "canonical" form (XML) if required - that is where the WSDL mappability comes in. Where there IS an opportunity for avoiding serialization is for remotable interfaces which are marked "AllowsPassByReference" - then, if the target happens to be local you can use pass by ref and avoid any serialization. Optimization of this kind will require some smarts in the invocation chain - but it is all clearly marked in terms of the SCDL. But I fail to see how failures can occur for "unnecessary pass-by-value" copies in any circumstance other than one that SHOULD be an error. Or am I missing something here? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming http-* modules to host-*
Jean-Sebastien, +1 from me, Mike. Jean-Sebastien Delfino wrote: To be more consistent with the other host-* modules, I'd like to rename http-jetty to host-jetty and http-tomcat to host-tomcat. If there's no objection I'll do this in the next couple days. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Implementation.spring Questions
Hi, Sorry, I've been a bit slow getting to your questions. [EMAIL PROTECTED] wrote: We were looking into using implementation.spring, but had a couple of questions. We have a spring context with elements common across all of our services (aspects, host connection beans, caching, etc.) so we've been using the singleton version of the application context in our system. How are you using that singleton version of the application context? Can you describe its configuration and use in some more detail, please. Is there actually any way with implementation.spring to configure which application context Tuscany will use? Not with the current implementation - an application context is created from the file identified in the element. Will Tuscany share Spring contexts if they are based on the same file? Not currently. But in SCA terms, this is not the way I would look at the requirement. If I understand things properly, it sounds as if you want to have a Spring component shared by a bunch of other components - and that you want a single copy of the shared component. In SCA terms this smacks of being a composite-scoped component (ie there is a single copy of the component instance used for all invocations of services of the component). Or maybe some way to configure the scope? Not at the moment - the current Spring implementation does not handle Scope - but I'll be happy to work on it with you. Scope has been implemented for SCA Java POJOs and I'm sure that it would not be too big a deal to extend that to Spring components. Also, we haven't fully investigated yet, but it seems like only one bean is being properly exposed as a service in a single Spring component. Is this by design? OK, the code is designed to expose as Services as follows: a) If there are explicit elements in the application context file, those and only those are exposed as services (one for one) b) If there are NO explicit elements in the application context file, then each bean in the application context is made into a service. If you're only getting one service then this may well be a bug. Are you able to share your application context with me - or provide a simple testcase that shows the failure, please? Any answers would be much appreciated. Glad to work with you - nice to have some real users ;-) Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Jean-Sebastien, Jean-Sebastien Delfino wrote: Looks like option (B) is the most preferred option with: - one -1 - five +1 - one "more spec compliant" Do we need more technical discussion? or a new [VOTE] thread to close this issue? Thanks for a great summary. I'm happy with the conclusion. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Brady, A warm welcome... Mike. Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating PolicySet attachments in SCA Artifacts.
Folks, Jean-Sebastien Delfino wrote: I would be surprised if impl="axis" was actually in the SCDL. Instead I'd imagine that impl="axis" would be a characteristic of a particular implementation of , not exposed to app developers but used by the policy framework to either select that axis-based implementation over another one when it sees that policy, or validate that the implementation in use in your runtime configuration can actually apply the requested policy. So basically, an SCDL-only based approach may not work, and I'd suggest to seek clarification from the SCA spec workgroup before going down that route. Nope, the spec intention is only to "validate" against the SCDL - nothing else is involved. Really "validation" isn't what's going on here. Those @appliesTo attributes are used to say what kind of element the PolicySet is designed for. It is really simply a way of rejecting PolicySets not designed for the element you're processing. The example involving @impl="axis" is actually a poor one. It assumes that is extended with an attribute @impl, which then has some range of values which reflect the available implementations of binding.ws - "axis" being one of them. But this attribute would have to be in the SCDL, for sure. What you do have to know is that when you are processing some element that can have intents / policySets applied, then both those on the element AND those in ancestor elements form a set which you have to scan in order to pick out the right one(s). So, you look upwards from the current place and pick out those that apply. XPath is used since not only the element itself can control whether to use the PolicySet, but also its attributes. The process is not so simple, I would certainly agree, but validation is not the issue - it's a "simple" case of selection that is going on here. Now, if I can help with more specific points of the algorithm, I'm happy to try to deal with them in other emails Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming binding-ajax to binding-dwr?
+1 to the rename. Best to name the binding by the transport mechanism involved, not the implementation used to drive it. Yours, Mike. Jean-Sebastien Delfino wrote: ant elder wrote: On 8/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I'd like to rename binding-ajax to binding-dwr, as Ajax is a really generic term, and it will make clear that this binding is actually using the DWR (Direct Web Remoting) protocol. Thoughts? Right now that it uses DWR is an implementation detail thats not exposed anywhere, just as Axis2 is not exposed anywhere in our binding.ws, so really we can call it whatever we like. Axis2 is an implementation detail, and that's the reason why we do not say in SCA. However, the protocol used to expose a service in an SOA is not an implementation detail at all... Here are three examples: binding.ws -> the SOAP protocol is used to talk to the service binding.jsonrpc -> the JSON-RPC protocol is used to talk to the service binding.ajax -> the Direct Web Remoting protocol is used to talk to the service Binding.dwr will better indicate than binding.ajax that the service is provided through the DWR protocol. To web clients binding.jsonrpc used to work acidentically to binding.ajax but the last couple of changes to binding.jsonrpc mean they've now got out of sync. If renaming binding-ajax will help you engage in keeping these both updated to work the same then Yes! lets rename it. ...ant OK, I'll rename it then. If you're talking about the change to how service URIs get determined, I'll be happy to help make it work like the other ones, but... - it didn't seem like it was initially working like the other ones, as it hardcoded a single URI and didn't use the binding URI at all, here's the code I found: public static final String SERVLET_PATH = AjaxServlet.AJAX_SERVLET_PATH + "/*"; and servlet.addService(binding.getName(), type, proxy); - answering my question on this subject at [1] would be a good starting point [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Folks, In some ways, I'm glad I was on vacation while much of this debate raged!! ;-) Comments below. Jean-Sebastien Delfino wrote: [A] What we have right now, standard SCA extensions and tuscany extensions sharing the standard SCA namespace (B) What IMO is a more correct use of XML namespaces, standard SCA extensions in the standard SCA namespace, and Tuscany extensions in a Tuscany namespace [C] What an application developer could write if we allowed namespaces to be omitted .. Now here are a few "side effects" :) Option [A] - I cannot validate this composite against the standard SCA schemas (it'll show errors in my XSD aware XML editor) our Tuscany extensions violate the standard SCA namespace - I have one less namespace and prefix declaration to care about Option [B] - I can validate this composite against the standard SCA schemas, as the Tuscany extensions match the xsd:any namespace="##other" extensibility points in the SCA schema - I have one more namespace and prefix declaration to write covering the Tuscany extensions Option [C] - I don't need to worry about namespaces, which are usually long and error prone, writing the composite is simpler - I cannot validate this composite against the standard SCA schemas as it does not declare namespaces My preference is to do both: - [B], be correct with respect to our usage of XML schema, to make people who care about XML schema validation and use XML schema tools happy - and [C] allow people who don't like namespaces to not have to write them Why do I like [C] as well? Here are a few examples: Hello! I can write XML without namespaces, isn't that nice? An axis2.xml configuration file http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml An MS WCF configuration http://msdn2.microsoft.com/en-us/library/ms735103.aspx A Tomcat server.xml file http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html All work without namespaces... Let me tackle them in reverse order (the more debateable first) C) Yes, this is indeed simpler. No namespaces is wonderful. (PS I will declare here that I am no fan of XML, so less XML always keeps me happy) The downside of this is that it "assumes" that you know all the valid XML in advance, if any validation is going to be done. I suppose that you have options: - 1. Don't worry about validation at all. - 2. Do validation and have some non-namespace way of knowing all the XSDs that contribute. The problem really hits when you start to build SCA Assemblies using tooling that is not part of Tuscany. The SOA Tools project at Eclipse comes to mind. We may come up with some approach for Tuscany, but can that also be used for the SOA Tools project? Namespaces may be ugly but at least they represent a standard that all can use B) This is the SCA spec approach. I'd recommend at least supporting this even if other techniques are also allowed. A) Is really problematic. It implies hacking the XSDs defined by the SCA specs. How will anyone know when they have violated the spec XSDs that form part of the Portability conformance that is part of the value of SCA (ie build and run my stuff on Tuscany and the same stuff should work on Oracle's runtime, if I stick to the stuff defined in the SCA specs...). A will also imply the existence of at least 2 sets of "SCA XSDs" - the spec ones and the Tuscany ones. How will anyone know which one they've got in their hands? So: A) -1not a good place to be B) +1its the standard C) +0.5 I can envisage this as +1 if it is an optional setting that a user can knowingly choose to use - as long as it is clear what they lose Yours, Mike. PS The Microsoft WCF config works without a namespace since I think it is not extensible, unlike SCA which allows all kinds of extension. PS 2 If anyone can think of a better way for SCA to handle its extensibility, that will allow us to drop namespaces, the spec team will be all ears. The spec group debated the use of namespaces at some length before adopting the current spec definition (and I was one of those trying to keep namespaces out of it). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec clarification for conversational/callback semantics: Reply #2
Simon, Yes, you've hit one of the parts of the Java spec that makes me least comfortable. The idea of sending around a reference for others to use is not something that fills me with joy, when that reference is essentially a reference to an instance. I feel the religious debates about WS-Addressing coming on Once instances can disappear in a puff of smoke, this whole area of function gets to be very uncomfortable. Furthermore, if you did the passing around in the case of a callback service, who does the provider get to talk with??? Simon Laws wrote: Yes, I think so. From a specification point of view I was worrying about the expected timescale of resource removal. Your assertion that it means that the conversation cannot be reused clarifies this point. I'm not sure I agree with the MAY in the sentence "depending on the implementation of the comms mechanism between client and provider that MAY require some additional communication to travel from the client side to the provider side.". I can't square this away easily with the requirement of section 1.6.3 of the Java Annotations and API spec to allow for the passing of conversational services as parameters where, if I understand it correctly, a third party could be holding a reference to a conversation for which the original client now calls Conversation.end(). Here a timeout is not good enough and the service should be aware that the conversation has ended. I suppose the MAY clause can be seen as being associated with whether any references have been copied or not. If not, there are no worries. At least the sending of a reference can in principle be detected since it can't be used unless instantiated by some (SCA) runtime. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec clarification for conversational/callback semantics: Reply #1
Simon,
Comments replies inline
Simon Laws wrote:
Thanks for the clarification. I think the separate discussion of
@Conversational and @Scope("CONVERSATION") provides a good basis for
clarification in the specifications. So a further small point of
clarification on this topic.
This is about understanding the behavior of the callback and is regardless
of the @Scope annotations of client and service provider ends of our
callback scenario
Scenario1
===
Callback is @Conversational / Service Provider is @Conversational
This relates to your point a). The conversation will encompass the client
(in as much that it initiates the conversation and provides a conversation
id), the service provider and any callbacks. The net result is that state
maintained by the client based on the original conversation id is accessible
to the callback based on the conversation id it is provided with. Also the
service provider is able to correlate state across calls to it based on the
same conversation id.
Yup, all that is true. This one is easier to understand. Stateful
service with asynchronous interaction style. eg
"Place an order for these widgets: 1, 2, 3, 4"
/ "Ack - order # abcd - will give status of widgets when I am able"
/ "Widget 1 ready for dispatch"
/ "Widget 2 ready for dispatch"
"Status of order abcd?"
/ "Widgets 1 & 2 dispatched - Widgets 3 & 4 outanding"
/ "Widget 4 dispatched"
/ "Widget 3 unavailable in required timeframe"
...where the receiving service provider itself has to depend on other
asynchronous providers
Scenario2
Callback is @Conversational / Service Provider is not @Conversational
Is this valid/sensible? Is the client able to correlate callbacks with the
original request based on conversation id in this case or must it rely on
callback id, i.e. the conversation id is simply for correlating one callback
with the next?
On the SCA spec mailing lists, we've dubbed these cases "mixed
conversational callbacks". They are allowed, but you have to question
the use cases carefully.
This would say that the original client is not concerned to be able to
tie the callback invocations to the original call - only to be able to
tie together a series of callbacks (ie the callbacks share state as far
as the client is concerned). This might make sense - eg accumulate a
set of data as the callbacks occur until the conversation ends. If
there is an unknown number of callback invocations, this might be
reasonable.
I think there is a need to construct a convincing example here. I
haven't thought of a good one yet.
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Spec Related] 'provides' attribute in PolicySet
Venkat, I was out on vacation when your original question was posted, so here's my contribution. Venkata Krishnan wrote: Thanks Raymond. A few more questions ;-) - The xsd defines the name attribute for PolicyIntent and PolicySet as of type NCName. However we have model these in the model classes QNames. I am assuming that the namespace uri for all intents and policyset defined in a specific definitions.xml is the value of the 'targetNamespace' attribute of the 'definitions' element. Is this right? Typically, all declarations of name elements for elements which live in a particular namespace are defined in the XSDs as NCNames (see Composite, for example). It is usual for the targetNamespace to declare the namespace into which the elements are being declared. So, in this case for the intents & policySets, you're right, we'd expect the targetNamespace to be used. Anything else would look distinctly odd. - Can a qualified intent have its qualifiable parent intent belonging to a different targetnamespace. If so how would this be evident from the name of the qualified intent? For example if there is an intent a:intentOne and then there is a qualified intent over this like intentOne.intentTwo - how is to be inferred that intentOne belongs to a different namespace Hmm, we had never intended this. I'd expect the qualified intent and its qualifiers to be in the same namespace. It's not outlawed for them to be in different namespaces, but I've no idea how you would express the definition to indicate this. Thanks - Venkat Hope this helps, Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec clarification for conversational/callback semantics: Reply #2
Simon, OK, Part 2 of my reply Simon Laws wrote: 2/ The specifications describe the freeing of state associated with a conversation when Conversation.end() is called on a conversation object . See section 1.6.5 of the SCA Java Annotations and APIs V1.0 specification. Assuming that the Conversation object is available from a service reference within the client of the conversation then, in the current implementation, the state associated with the conversation held by the service will not be freed directly if end() is called. A separate message exchange would be required between client and service to carry this end() instruction directly. As it stands the target conversation will eventually time out. What is the specification's intention in this case? Regards Simon I think I'm going to need your help to work out exactly what the problem is here. The specification identifies a number of ways in which a conversation may end, in 1.6.5, as you say. Some of the methods of ending a conversation make it clear that communication occurs between client and provider (eg an @EndsConversation method is called). These cases ensure that both sides of the conversation can deallocate resources at the "same time". In the other cases, the spec does not make it a requirement that communication occurs between client and provider. However, neither does it forbid it. What does need to be clear is that the conversation is ended and that it cannot be reused - depending on the implementation of the comms mechanism between client and provider that MAY require some additional communication to travel from the client side to the provider side. A design that uses timeouts on the provider side is OK, as long as the requirement that the conversation cannot be (re)used once the end() method has been called is satisfied by the runtime/binding implementation. Have I hit the mark with my response? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec clarification for conversational/callback semantics: Reply #1
Simon,
I'm breaking my reply into two parts, each dealing with one of the
issues you raised originally:
Simon Laws wrote:
1/ Stateful Callbacks - Given the the following scenario where the
ConversationalClient has a reference to a ConversationalService
@Remotable
@Conversational
public interface ConversationalCallback {
...
}
@Remotable
@Conversational
@Callback(ConversationalCallback.class)
public interface ConversationalService {
}
@Scope("CONVERSATION")
public class ConversationalClientImpl implements ConversationalClient,
ConversationalCallback {
@Reference
protected ConversationalService conversationalService;
}
@Scope("CONVERSATION")
public class ConversationalServiceImpl implements ConversationalService {
@Callback
protected ConversationalCallback conversationalCallback;
...
}
In the current implementation the specification has been interpreted to mean
that the "client" component, i.e. the component implementing the callback
interface, must be marked as having conversational scope if it is required
that callback messages return to the same instance of the client component
that originated the conversational call. Is this the correct interpretation
of the specification, in particular Section 1.6.7.1 of the SCA Java
Annotations and APIs V1.0 specification.
Strictly speaking, Conversation SCOPE is independent of the
@Conversational marking of interface(s) for a service.
To clarify: It is possible to implement Conversational interfaces using
code that is itself stateless (ie does not matter which implementation
instance receives a given message), since the code can be written to
look up the conversation ID and save/retrieve conversation state data
using some backing store. For long running conversations, this design
pattern is usually preferable since the container is not burdened with
maintaining a lot of quiescent instances and the state data is "backed up".
However, Conversation scope is a very useful way of marking
implementations which have to deal with Conversational interfaces, since
it removes the need for the programmer to do explicit management of
state. Marking an implementation with conversational scope is a request
that the container of the component performs the state management.
The only way to guarantee that the same client instance and the same
server instance are involved for every operation of an interface
involving a callback is to mark both the client implementation and the
server implementation with Scope "CONVERSATION". This must be in
addition to both the "call" interface and the "Callback" interface being
marked with @Conversational. In implementation terms, I then view this as:
a) The @Conversational marking ensures that a unique ID is associated
with the messages transmitted from Client to Provider and with the
messages from the Provider to the Client (note in the callback case, the
callback operations are in principle completely asynchronous in relation
to the call operations - and the number and type of callback operations
for a given call operation is completely variable)
b) The @Scope("CONVERSATION") marking on both the client implementation
and on the provider implementation then flags up to the container(s)
that the instances on each end have an extended lifecycle associated
with the conversational interfaces and that the conversation ID should
be used by the container to select the appropriate instance to receive a
message.
An errata is in process of being raised against the Java Annotations and
APIs spec to make a clarification along the lines I've written here -
I'd appreciate feedback on whether my words here are clear and would
improve the spec if added there.
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I think Tuscany needs a graph generator for composite layouts
Shaoguang, The Eclipse SOA Tools Project is building a graphical editor for SCA composites. You can find the project here: http://www.eclipse.org/stp/ In addition to the graphical composition editor, there is a range of SCA and SOA related tooling available in this tools project. Of course, there are also commercial tools produced by some vendors, of which the IBM WebSphere Integration Developer (WID) tool is an example: http://www-306.ibm.com/software/integration/wid/ ...the commercial tools are big on graphical editors, but as you might expect for such productive tools, they come at a significant price! Yours, Mike. shaoguang geng wrote: as the title, when composite contents comes more and more complicated, a layout graph generator would do greate help to developers. Or did some one see commercial providers of such a grapher? Good day. - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Folks, I agree with Simon's comment - this resolution violates the SCA spec. You are not supposed to go adding stuff to the SCA namespace that is not approved by the SCA spec process. In particular, no additions to the sca.xsd or sca-core.xsd are allowed. Yours, Mike. ant elder (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1053. -- Resolution: Fixed Closing as it looks like we've standardized on using the SCA namespace Use a Tuscany namespace for all non-spec'd Tuscany extensions - Key: TUSCANY-1053 URL: https://issues.apache.org/jira/browse/TUSCANY-1053 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-Next Currently Tsucany extensions use SCDL elements is varrious different namespaces. There should be a single Tuscany namespace that extensions not defined by SCA spec's should use. See http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200701.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to create new Jira Issues - get a null pointer
Mark Combellack wrote: Mark Combellack <[EMAIL PROTECTED]> writes: Mike Edwards ...> writes: Mark Combellack wrote: Is anyone else having problems creating new Tuscany Jira bug reports? I am logged into Tuscany Jira at: https://issues.apache.org/jira/browse/Tuscany I've tried creating a new Tuscany issue of type bug and I get the following error: System Error I've just tried creating a Jira issue from home and it works. Looks like it is a proxy issue from work :-( Time for me to contact our IT department. Mark Mark, Ugh, sorry to hear that. Hope that you get it fixed soon. Homeworking has its upsides ;-) Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Contribution provisioning and updates
Simon Laws wrote: In the distributed domain contributions and any updates have to be provisioned to each node. There are many ways of doing this, ftp, http, shred file system , etc. to the extent that Tuscany shouldn't really care too much about how it is achieved. I would expect that at any give time a domain at a node can be notified of its configuration given the URL(s) of where to find its up to date contributions. For example, in the stand alone case this could just resolve to the contributions in "file:///path to sca-cntributions dir". However I'm a little unclear how to deal with configuration updates. There have been a number of posts recently about incremental updates to domains [1] and [2]. I can see that contributions can be added and removed but the implication of the discussion in [1] and the assembly spec (1.10.4.1) implies that contributions can also be updated. Is there code to support this in place already? I'm assuming the current approach is to drop the current contribution and load the updated version rather than deal with deltas. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19979.html [2] http://issues.apache.org/jira/browse/TUSCANY-1379 Simon, I think it will pay to do a bit more thinking about all this. There are going to be a range of different configurations to support, and so thinking through the structure of the runtime nodes and how they interact with the contributions in the Domain will pay off over time. I think there is going to be too much to contain in one email, but I'll start here. I think capturing the concepts on Wiki pages will pay off in the long run, since I think that sorting through a load of emails to find them will get hard. So, if you are all seated comfortably, let us begin (Brits of a certain age will understand where that phrase comes from...) We have the SCA Domain. This contains the configuration data, held as a series of one or more contributions. On a single node runtime, the way in which the Domain is held can be very simple indeed. Files on disk in one or more directories will do fine. Once we get a distributed runtime, things rapidly get more complex. The one obvious thing is that it is almost inevitable that each runtime node will need access to parts of the SCA Domain configuration that they don't "own" - eg to make a wire from a component that one node runs to a component running on another node. How the SCA Domain is done for a distributed runtime is also variable - it could be done in a number of ways. The trick is to provide interfaces between the runtime node code and the "repository" that allow for alternative implementations. This must include both the initial configuration when the runtime node(s) start up and also what happens when the Domain configuration changes. I think that we must design interfaces that separate the organization of the SCA Domain repository from the runtime code. These interfaces are going to have to be two-way, in the sense that there is going to be both pull and push aspects to them. ie A node can go pull configuration information from the Domain, or it can have configuration thrown at it - either as updates or by some provisioning manager that is tossing out work to do. Service interfaces seem like the right kind of things to do under the covers inside the implementation of the Domain repository. Nodes in principle need to talk with each other. We need to think through which interfaces are needed first and then decide how they are dealt with in terms of concrete service interfaces. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Jean-Sebastien Delfino wrote: Huang Kai wrote: Hi, Raymond, We encountered the same problem when implementing SDO's XSDHelper. Where we used EMF's xsd tool package for resolve xsd. Wherein we just implemented our own XSDSchemaLocator and added it to the resource's adapters, then we can do everything in locating the import/include xsd. It works fine. I don't know if XmlSchema have any thing alike. Good point, and if we're going to tweak the resolution mechanism for XSDs with some specific SCA resolution rules, then we need to make sure that it's done in a consistent way: - at runtime, under XmlSchema library - at runtime, in the XSDHelper - at codegen time (XSD generation and WSDL2Java) - at codegen time under the JAX-WS / JAXB generators - in my XSD editor - in my XSD validator - in my WSDL editor - in my WSDL based Web Services test tool - and in all the other Web Services implementations out there if we want them to support these WSDLs and XSDs. etc... Does this still sound like a good idea? ... I'm not sure. If we don't cover all these aspects, is this custom resolution going to help the app developer? or get in his way? ... I'm positive that it'll get in his way :) So I'm sure that we should use the SCA resolution within SCA artifacts. Using it to resolve references between XSDs sounds either very ambitious, or pretty dangerous to me... Jean-Sebastien, Well, maybe we SCA spec guys are more than a little crazy ;-) We had envisaged that for SCA, the Domain is built up from contributions - and that the contributions form a way of sharing artifacts, if required. This is deliberately intended to cover XML artifacts which not only include SCA things like Composites, but also XSD and WSDL. The idea is in principle a simple one - avoid using a plethora of separate mechanisms, which force the developer to supply a lot of detailed information. Instead have one simple overarching scheme that can be used for all artifacts. Maybe we had too much of the fruits of the vine when we devised this, but it is in many ways a kind of extension of the ideas of OSGi bundles, applied to the non-Java code artifacts that abound in these systems. Regarding use cases like XSD editing and WSDL editing, I would tend to agree that it would be best to do this in a situation where all referenced artifacts are in simple places (I recall the recent discussion between us about loading the XSDs into the Eclipse configuration location rather than relying on the location parameters in include elements). So perhaps only some of these scenarios need dealing with "in the SCA way" - and that these should focus on the runtime. However I can envisage that Eclipse STP may like to take on the challenge of creating SCA contributions with SCA resolution of artifacts from other contributions. Perhaps it isn't so crazy - it just needs a divide and conquer approach. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to create new Jira Issues - get a null pointer
Mark Combellack wrote: Is anyone else having problems creating new Tuscany Jira bug reports? I am logged into Tuscany Jira at: https://issues.apache.org/jira/browse/Tuscany I've tried creating a new Tuscany issue of type bug and I get the following error: System Error Mark, It is working for me right now - I just created a new Jira report. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1486) Support Stateful Spring Beans and Conversational interactions
Support Stateful Spring Beans and Conversational interactions - Key: TUSCANY-1486 URL: https://issues.apache.org/jira/browse/TUSCANY-1486 Project: Tuscany Issue Type: Improvement Components: Java SCA Spring Implementation Extension Affects Versions: Java-SCA-Next Reporter: Mike Edwards Assignee: Mike Edwards Priority: Minor Fix For: Java-SCA-Next Provide stateful support for Spring Beans, including Scope support and Conversational interaction support, -- 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: Resolving WSDL/XSD import/include for SCA contributions
Hi, A few thoughts >> We have two options here: >> >> a) Plugin a tuscany-specific resolver for WSDL4J >> (javax.wsdl.xml.WSDLLocator) and XmlSchema >> (org.apache.ws.commons.schema.resolver.URIResolver). >> >> This option can handle location case 1, 2 and 3. For 2, we probably need >> some context from the contribution service. >> >> The difficulty is that both resolvers expect to take an InputSource. For >> location case 4 (empty or not present), we don't have a corresponding >> InputSource. > > I was going to respond with a long list of pros-cons for both options, > then deleted all my comments to ask a simple question :). Why can't we > return an InputSource for the contents of the imported document? > > Well, for the import/include that can be resolved to a document, we > return the InputSource. I have said that it works for location case 1, > 2 and 3. But if the import/include only doesn't have the > schemaLocation attribute, what InputSource should we return? Well, it seems valid to me to go use the SCA resolution mechanism - it is simple enough to say, either use the WSDL or XML approach (and require a location) but if there is no location, then this isn't going to work and SCA takes over. I note that if the location is left out in the case of the included/imported file being in the same contribution as the source file, then things are simple and the SCA rules will find it. If it is elsewhere, then SCA at least defines an algorithm to follow to attempt to find the referenced file. > A related question, for an artifact processer that loads multiple > artifacts following the import/include directives, how can we avoid > the duplicate loading? For example, we have a.wsdl imports b.wsdl, > both a.wsdl and b.wsdl are in the same contribution and they are > processed by the WSDL artifact processor. We probably don't want to > load b.wsdl twice in this case. Why actually load anything before it is clearly required? But once it is loaded, keep it around. This should be true for all artifacts. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synapse using SCA assembly model for configuration
Paul, Great to hear from you! Some thoughts inline. Paul Fremantle wrote: I recently read Dan's blog entry on the SCA assembly model: http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/ That and some other discussions I've had made me think about maybe offering the SCA assembly model to configure Synapse. So it seems to me that you can draw a direct correlation between: Synapse Proxy and SCA Service Synapse Endpoint and SCA reference Synapse Mediator - a specific type of SCA Component Synapse Property - SCA Property It certainly looks like a reasonable mapping. If we were to make the XMLConfigurationBuilder pluggable then we could just use this as an alternative configuration language. We did talk about this in the beginning of Synapse [we discussed having a LEX/YACC style config language - which I would still LOVE if someone wants to do that - it would make a great Computer Science project] Anyway back to SCA, it seems to me that this would be a pretty nice alternative config model, using an independent third party language. I'm guessing that there is plenty of Tuscany code could help us implement this. Maybe we might do it jointly? So I'm imagining the existing runtime being *exactly* the same as today, but being able to use a subset of the SCA Assembly model to configure it. Maybe some of the SCA wizards on tusc-dev can jump in and let me know if this is feasible? SCA makes no assumption about the runtime at all - and the spec teams have always viewed the SCA model as being mappable to a whole range of runtimes, so this way of thinking about things is fine. Indeed, some of the work in the Eclipse tools project is done this way, where an SCA model is used to describe the solution in the tools and is then mapped to the configuration file format of a particular runtime. The runtime never sees the SCA metadata directly. Your idea is to do this mapping at runtime - I happen to prefer that way of doing things. One BIG question to ask is whether you want to support implementation artifacts with SCA annotations. SCA supports, for example, Java classes with annotations which configure them with a range of features - this is an alternative to providing the information in the SCA XML format. Doing this requires appropriate introspector code in the runtime. This can certainly come from Tuscany. Paul PS If someone is looking at http://www.infoq.com/news/2007/07/scaproblem and wondering where this is coming from I offer a few thoughts. Firstly, I'm always open to being proved wrong! Secondly, this would not be adding any layers of indirection... I'm mapping directly from SCA concepts into the Synapse runtime with this idea. Finally, I see nothing wrong with holding several inconsistent viewpoints at the same time :) This direct mapping of SCA metadata into runtime entities is behind my contention that SCA does not add any layering. SCA is not about indirection, rather it is about having a consistent way of describing SOA configuration, which is mapped to the specifics of given component and runtime technologies. Only where it is the intention to extend the runtime(s) involved (eg with support for new bindings) would there need to be any consideration of layering - but then it is a question of how the runtime itself is written - the ideal is no layering, but a simple addition of function. As for holding multiple inconsistent viewpoints at once - politicians seem to manage that as a way of life ;-) Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Raymond, How does this relate to the contribution resolution mechanism described by the SCA specifications? Yours, Mike. Raymond Feng wrote: Hi, We currently use XmlSchema to load XSDs. To resolve the import/include directives using our schemes, we provide an implementation of org.apache.ws.commons.schema.resolver.URIResolver and set it to org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the schemaLocation attribute for the or is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, http://ns1"/>. Without the schemaLocation, we resolve the import/include by namespace. In this case, we already have a map keyed by namespace for a list of XmlSchema objects loaded from a catalog or other files and we want to reuse them. Would it be possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that we can override/customize the behavior to associate existing XmlSchema instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to keep the schema map is not always feasible. Another observation is that a NPE will be thrown if the URIResolver.resolveEntity() returns null. Is there any way to disable the aggressive resolving/loading of import/include? [EMAIL PROTECTED] Raymond Feng Apache Tuscany - 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: Why SCA10 specify
Hi Shaoguang,
shaoguang geng wrote:
In SCA java component implementation 1.0, most of the spec was telling the story about . But in fact has done every thing.
Dose osoa mean: using the interface MAY NOT BE an interface of
the implementation class?
SCA follows the principle of Service Oriented Architecture in separating
the interface of a service from its implementation.
So, where you have a service component implemented by a Java class, it
is expected that there will be an interface definition for the service
offered by the component. This service interface must be one of the
interfaces implemented by the Java class.
So, let us say that we have a service which is defined by the Java
interface:
com.foo.ServiceA
And that we have an implementation of the service provided by a class
com.foo.ServiceImpl
The ServiceImpl class is going to look something like this:
package com.foo;
public class ServiceImpl implements ServiceA {
public String someOperation( String bar ) {
...
...
}
}
Note that the class implements the interface com.foo.ServiceA - if there
is only one interface implemented by the class, this will be assumed to
be the service interface provided by the class. If there are multiple
interfaces implemented by the class, the SCA @Service annotation can be
used to indicate which service each interface belongs to.
In a composite file which holds the service component, the declarations
could look something like this:
http://www.osoa.org/xmlns/sca/1.0";
name="CompositeA">
...
So, this says that the component named ServiceAComponent is implemented
by the class com.foo.ServiceImpl. That component has a service with the
name ServiceName which has an interface described by the Java interface
com.foo.ServiceA.
Strictly speaking, writing out the element in full like
this is not necessary in the composite file - the information can be
introspected from the Java class - but it is valid to do this.
Note that while the Java interface may be used to define the service in
the Java class, it is possible to use a different interface language
like WSDL in the composite file, as long as the WSDL definition and the
Java definition of the interface match each other.
I hope that this helps explain things.
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAP over JMS?
Simon Laws wrote: Ah, thanks Mike. I didn't latch onto the implication of the word intent. The choice we are talking about here seems more like a concrete decision than an intent. Does this match well with the, erm, intention of intents? Simon It is one use of intents - and, in my opinion, it is a reasonable match. It tells the binding to apply a particular policy - the policy of using a specific transport. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAP over JMS?
Simon Laws wrote: On 7/24/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Simon Laws wrote: > Has anyone in Tuscany made a binding that ships SOAP messages over JMS > instead of HTTP? Looking at the current code base and at the old code in > the > sandbox I don't see anything. > > Simon > Simon, Shouldn't this be a "simple" extension of the Web services binding? The interesting question is how to indicate that a JMS transport should be used instead of HTTP. The spec only allows for this to be done via WSDL at the moment - not so good if you didn't want to create the WSDL yourself. How about the idea of adding an intent for the Web services binding which can be used to indicate the transport?? eg: transport.http = use the HTTP transport (default) transport.jms = use the JMS transport transport.foo = use the foo transport The Web services binding can indicate which of these intents it supports - since that depends on the support being available in the Web services stack that you are using. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So you would end up with Is that right? Nope. That's not what I mean. Sorry but I assumed too much knowledge of the SCA Policy spec... What you would get is this: or If you require specific configuration details for the given transport, then this would have to be supplied by additional attributes or by additional child elements. The URI attribute is one possible approach, but it can get to look very messy very quickly. Whether you need a load of configuration really depends on whether you are going external to the SCA Domain. If you are going external, then detailed config is probably necessary. However, some good sensible defaulting can probably give a usable service with minimal information. References are a different matter since the target endpoint is what it is. Using SOAP over HTTP should in principle simplify things to some extent since the message format is "known" and hence there is less configuration required. Hope this helps, Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAP over JMS?
ant elder wrote: Couldn't this just use the existing Axis2 facilities, the soap/jms uri format and be done with the scdl binding uri attribute, eg: org.apache.activemq.jndi.ActiveMQInitialContextFactory&java.naming.provider.url=tcp://localhost:61616&java.naming.security.principal=system&java.naming.security.credentials=manager" /> ...ant "Simple" that ain't ;-) Agreed that if you get into requiring all those details, that is one way to supply them. As Simon notes elsewhere, the JMS binding provides a more structured way of providing all that gorp. I was hoping for something simple, but perhaps I'm being too simplistic. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SOAP over JMS?
Simon Laws wrote: Has anyone in Tuscany made a binding that ships SOAP messages over JMS instead of HTTP? Looking at the current code base and at the old code in the sandbox I don't see anything. Simon Simon, Shouldn't this be a "simple" extension of the Web services binding? The interesting question is how to indicate that a JMS transport should be used instead of HTTP. The spec only allows for this to be done via WSDL at the moment - not so good if you didn't want to create the WSDL yourself. How about the idea of adding an intent for the Web services binding which can be used to indicate the transport?? eg: transport.http = use the HTTP transport (default) transport.jms = use the JMS transport transport.foo = use the foo transport The Web services binding can indicate which of these intents it supports - since that depends on the support being available in the Web services stack that you are using. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release process & guide & checklist, was Fwd: [VOTE] Release SDO Java 1.0-incubating
Luciano Resende wrote: Should we start thinking on a formal release guide, merging together couple documents we already have as of today, and also creating a checklist as it looks like couple release candidates are having the same issues ? +1 - yes, most definitely. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514610 ] Mike Edwards commented on TUSCANY-1389: --- I'm OK with Jean-Sebastien's proposal. It would be useful to update the website/Wiki documentation to describe this approach. > published DTD for composite XML Schema needed/useful > > > Key: TUSCANY-1389 > URL: https://issues.apache.org/jira/browse/TUSCANY-1389 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA > Samples >Affects Versions: Java-SCA-0.90 > Environment: java >Reporter: James Tomkinson >Priority: Minor > Attachments: addattributes_knownfromDTD.jpg, > addchild_knownfromDTD.jpg, openwithxmleditor.jpg > > > Samples should supply a DOCTYPE in *.composite xml files, that points to a > stored DTD, so that XML editing tools can be used to create/edit/validate XML > schema. This will enhance productivity/accuracy. > Example for Hibernate: >"-//Hibernate/Hibernate Configuration DTD 3.0//EN" > > "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";> -- 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: XSDDocumentProcessor visibility
Luciano, Yes, make it more widely available. Yours, Mike. Luciano Resende wrote: Looks like XSDDocumentProcessor is not being registered with the proper artifact extension point, and it's being only available internally to the WSDLDocumentProcessor. Should we register it with the extension point to make it more widely available ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversational - spec question
Folks, It is clear from reading other sections of the specification that it is intended that @ConversationID is used in implementation classes other than those of CONVERSATION scope. Further down in 1.2.51 of the JavaComponentImplementation spec, it says the following: 1. The implementation can be built as a stateless piece of code (essentially, the code expects a new instance of the code to be used for each method invocation). The code must then be responsible for accessing the conversationID of the conversation, which is maintained by the SCA runtime code. The implementation is then responsible for persisting any necessary state data during the processing of a method and for accessing the persisted state data when required, all using the conversationID as a key. This is clear that stateless (ie NOT CONVERSATION scope) implementations can use the conversationID. So I think that @ConversationID is always actioned - the only difference is how often it gets actioned (a CONVERSATION scoped implementation gets it just the once, while every invocation of a stateless will require injection). Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on callback bindings
Simon Nash wrote: I am implementing approach 1). The code is turning out to be straightforward and this approach fully supports the SCA callback spec AIUI. The Axis2 callback MEP isn't the same as an SCA callback, and it's confusing that these have the same name. With the Axis2 callback MEP, the forward call is sent asynchronously, and the callback message carries the result from the forward call. In SCA, the callback is a normal call made in the reverse direction, and the signature of the callback is unrelated to the signature of the forward call. Simon Folks, This is the correct interpretation. SCA callback is very general and make no assumption about the nature of the transport used between the reference and the service. The call interface has each method able to be a full request/response, if that is what is required. They can of course have a void return or be a OneWay invocation. The callback interface equally allows each method to be a full request/response or a OneWay. There is no assumption made about the number or the timing of the invocations on the callback interface related to a given invocation on the call interface. Indeed, SCA today has no metadata that captures these relationships (it has been suggested quite seriously that it might be possible to capture this metadata as an abstract BPEL process, but this has not been progressed as a formal addition to the Assembly specification). So, the correct behaviour is for the call to be treated as a regular SOAP/HTTP interaction, completely independent from any callback interaction. A given call may result in 0, 1 or many callback invocations. A simple example might be a service for placing an order. The "place order" operation may be request/response with the response acting as a "ack" that the order was received. However, the "place order" may then be followed by callbacks like the following: - "order accepted" - once credit checking and item availability checks are done - "order dispatched" - once the order items have been packaged and dispatched to the shipper Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r557494 - in /incubator/tuscany/java/sca/samples: calculator-rmi-reference/src/main/resources/ calculator-rmi-service/src/main/resources/ calculator-script/src/main/resources/ calculat
Luciano Resende wrote: The targetNameSpace were only added on the Calculator and Chat samples, as suggested on the JIRA 1330. The other changes were merely cosmetic (such as alignments) or adding missing headers on some composite files. What's the suggestion here ? To remove the targetNamespace from the Calculator samples ? Umm, sheepish grin. This has revealed an erratum in the spec. The Assembly spec contradicts itself by saying that the targetNamespace attribute on a composite is optional (line 1033) but in the XSD and in the pseudo-schema, it says that it is required. Oh well, I'll raise this with the spec group and get a resolution My own opinion is that targetNamespace is essential only if there is a desire to share the composite between contributions, since then there must be a means to find the composite from a "remote" place. However, other spec team members may prefer the "required" approach to avoid errors I certainly was arguing to remove the targetNamespace from the samples, since it had no use (didn't show anything useful in terms of those samples). On 7/19/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, I tend to agree with Ant. The namespace gets necessary once we get into inter-contribution sharing of artifacts and then the namespace is essential, but I dont think it is necessary or useful in the simpler examples. I DO think we need to add the XSD location for the SCA namespace, however - this is useful for tooling using the composite files, for example. This is covered by JIRA 1443. Yours, Mike. ant elder wrote: > Do we really need these, line 1033 of the assembly spec says the > targetNamespace is optional, and the samples don't use the sample > namespace? As they're samples isn't it good to keep the XML as bare and > simple as possible? > > ...ant Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An idea for WS Reference
Shaoguang, The SCA specifications allow for the WSDL file to be referenced from a single location, which can include a remote location, via mechanisms such as wsdl:location or via the SCA artifact resolution mechanism (see SCA Assembly spec at www.osoa.org). So copying the WSDL file is not necessary. However, for a Java developer, there is usually the need to derive a Java interface from the WSDL in order to write the Java code for that interface. It is always possible then, that the Java interface gets out of sync with the WSDL file. There is no easy way around this, but the SCA runtime can at least check for compatibility and raise a fault if they do not match. Yours, Mike. shaoguang geng wrote: WS consumer will have to put a wsdl file in it class root, the SCADomain load it automaticly. But this brings a problem if the provider's wsdl changed. So first I think if the consumer could load the wsdl from http://[host]:[port]/[servicename]?wsdl,. There by, when debug the wsdl, the developer will have to edit on the two side. Would anyone think this a better idea? - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
[ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-1443: - Assignee: Mike Edwards > sample composite files are invalid instance documents against SCA schema types > -- > > Key: TUSCANY-1443 > URL: https://issues.apache.org/jira/browse/TUSCANY-1443 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA > Environment: all >Reporter: Michael Yoder > Assignee: Mike Edwards > > The SCA samples composite files are invalid against the SCA schemas. In a > component element, the property element has content. e.g. (from CppBigBank) > > . > EURO > > When the XML Schema type does not allow mixed or simple content: > > > > > > use="optional" /> > default="may" use="optional" /> > > > > > The type is open to additional attributes, so the instance documents can be > made valid with simple changes like this: > > . > > -- 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: svn commit: r557494 - in /incubator/tuscany/java/sca/samples: calculator-rmi-reference/src/main/resources/ calculator-rmi-service/src/main/resources/ calculator-script/src/main/resources/ calculat
Folks, I tend to agree with Ant. The namespace gets necessary once we get into inter-contribution sharing of artifacts and then the namespace is essential, but I dont think it is necessary or useful in the simpler examples. I DO think we need to add the XSD location for the SCA namespace, however - this is useful for tooling using the composite files, for example. This is covered by JIRA 1443. Yours, Mike. ant elder wrote: Do we really need these, line 1033 of the assembly spec says the targetNamespace is optional, and the samples don't use the sample namespace? As they're samples isn't it good to keep the XML as bare and simple as possible? ...ant On 7/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: lresende Date: Wed Jul 18 22:33:05 2007 New Revision: 557494 URL: http://svn.apache.org/viewvc?view=rev&rev=557494 Log: TUSCANY-1330 - Adding targetNameSpace to sample composites Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/chat-webapp/src/main/resources/chat.composite incubator/tuscany/java/sca/samples/das-service-web/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/das-service/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/helloworld-dojo/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/helloworld-jsonrpc/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/implementation-notification/src/test/resources/TrafficAdvisoryNotification.composite incubator/tuscany/java/sca/samples/simple-bigbank-spring/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/simple-bigbank/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/web-resource/src/main/resources/WebResource.composite Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite?view=diff&rev=557494&r1=557493&r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. --> http://www.osoa.org/xmlns/sca/1.0"; + targetNamespace="http://sample"; + xmlns:sample="http://sample"; name="Calculator"> Modified: incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite?view=diff&rev=557494&r1=557493&r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. --> http://www.osoa.org/xmlns/sca/1.0"; + targetNamespace="http://sample"; + xmlns:sample="http://sample"; name="Calculator"> Modified: incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite?view=diff&rev=557494&r1=557493&r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. --> http://www.osoa.org/xmlns/sca/1.0"; + targetNamespace="http://sample"; + xmlns:sample="http://sample"; name="Calculator"> Modified: incubator/tuscany/java/sca/samples/calculator-webapp/src/ma
Re: [jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
Brady, Well if the SCA CPP samples are using 0.96 they should not refer to the 1.0 XSDs - implied in the samples composite files. Or have I missed something? Mike. Brady Johnson wrote: Mike, TuscanySCA Native is using the SCA Assembly Model, version 0.96, and you're referencing version 1.0. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Michael Yoder [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 9:52 AM To: Mike Edwards (JIRA) Subject: RE: [jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types Thanks Mike! Yes, I was looking at the schemas in Tuscany source control. It looks like updating the schemas in Tuscany should address this issue (will make the instance docs valid). Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -Original Message- From: Mike Edwards (JIRA) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 7:41 AM To: Michael Yoder Subject: [jira] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types [ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.ji ra.plugin.system.issuetabpanels:comment-tabpanel#action_12513257 ] Mike Edwards commented on TUSCANY-1443: --- Umm, which SCA XSDs are you referencing here? The correct ones are in the SCA Assembly spec document here: http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf and they are also available directly on the web at their indicated locations, eg: http://www.osoa.org/xmlns/sca/1.0 In those, the definition of SCA Property type goes like this: use="optional"/> use="optional"/> default="false" use="optional"/> ...which I believe covers the usage described for the property in the composite document which you reference. Now, there is a problem with the XSDs within the cpp Project, but it isn't the one you've raised. Actually, the ones in the cpp project look to be out of date and need to be replaced wholesale with the ones from www.osoa.org. Yours, Mike. sample composite files are invalid instance documents against SCA schema types -- Key: TUSCANY-1443 URL: https://issues.apache.org/jira/browse/TUSCANY-1443 Project: Tuscany Issue Type: Bug Environment: all Reporter: Michael Yoder The SCA samples composite files are invalid against the SCA schemas. In a component element, the property element has content. e.g. (from CppBigBank) . EURO When the XML Schema type does not allow mixed or simple content: use="optional" /> default="may" use="optional" /> /> The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: . -- 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] - 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] Commented: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
[ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513257 ] Mike Edwards commented on TUSCANY-1443: --- Umm, which SCA XSDs are you referencing here? The correct ones are in the SCA Assembly spec document here: http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf and they are also available directly on the web at their indicated locations, eg: http://www.osoa.org/xmlns/sca/1.0 In those, the definition of SCA Property type goes like this: ...which I believe covers the usage described for the property in the composite document which you reference. Now, there is a problem with the XSDs within the cpp Project, but it isn't the one you've raised. Actually, the ones in the cpp project look to be out of date and need to be replaced wholesale with the ones from www.osoa.org. Yours, Mike. > sample composite files are invalid instance documents against SCA schema types > -- > > Key: TUSCANY-1443 > URL: https://issues.apache.org/jira/browse/TUSCANY-1443 > Project: Tuscany > Issue Type: Bug > Environment: all >Reporter: Michael Yoder > > The SCA samples composite files are invalid against the SCA schemas. In a > component element, the property element has content. e.g. (from CppBigBank) > > . > EURO > > When the XML Schema type does not allow mixed or simple content: > > > > > > use="optional" /> > default="may" use="optional" /> > > > > > The type is open to additional attributes, so the instance documents can be > made valid with simple changes like this: > > . > > -- 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: Click to confirm your Google Alert
Simon Laws wrote: On 7/17/07, ant elder <[EMAIL PROTECTED]> wrote: Fyi, I've taken the liberty of setting up Google blog alerts to send us msgs when sca or tuscany are found to be mentioned on someones blog, hope no one minds. Can switch them off if it gets annoying but I've been using this for a while and find it really useful to see what people are saying. ...ant -- Forwarded message -- From: Google Alerts <[EMAIL PROTECTED]> Date: Jul 17, 2007 1:19 PM Subject: Click to confirm your Google Alert To: [EMAIL PROTECTED] Google received a request to start sending Alerts for the search [ SCA SOA ] to [EMAIL PROTECTED] Verify this Google Alert request: http://www.google.com/alerts/verify?s=EID92dmrxGyH3Vsj1WImU9Q Cancel this Google Alert request: http://www.google.com/alerts/remove?s=EID92dmrxGyH3Vsj1WImU9Q Thanks, The Google Alerts Team http://www.google.com/alerts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This is sort of related. I just made a page on the wiki where I've started putting links to articles that people have written about Tuscany/SCA/SDO etc. I was just moving this info to a new machine and thought it better to store is somewhere more accessible. Feel free to edit. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Articles+About+Tuscany Simon You can also include pointers to the materials about SCA & SDO on www.osoa.org Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website ACL
Folks, I think that we should consider the idea of "Website Wiki committership" separately from "Code committership". I don't think that it should be necessary for someone to have Code committership in order to be granted update access to the Website/Wiki. I do agree that it needs to be controlled, but that we should draw up a wider list of folk who are allowed to edit material on the Website. As has been pointed out, updates to the website have slowed down since we restricted write access. This is not good. Our website needs plenty of work. Yours, Mike. Luciano Resende wrote: My only concern is that, after we restricted access to our wiki, and started using the process of JIRA or updates on the other wiki space, the website contributions basically stopped. I think we had only one JIRA created on this space. On 7/13/07, ant elder <[EMAIL PROTECTED]> wrote: On 7/13/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > I was referring to the following paragraph... > > "a CLA is required for cover substantial contributions for source. therefore > wiki karma must only be granted those with a CLA." Yes but that doesn't mean that the converse is also true, ie just having a CLA doesn't give the right to be granted wiki karma. +1 > Robert also says later on : > > "a committer is essentially a developer with a CLA " and also that "provenance needs to be established and oversight maintained" > If we have control to who gets access, and we are covered, on the > legal aspects, by having the CLA in place, we should be Ok. What are > your concerns here ? As with the code, it requires more than just having a CLA to be granted commit access to our SVN. > The other two alternatives I see are : > >- Make wiki patches, or copies from "ocpy of the website wiki" >- Make all website contributors a Tuscany committer +1, both of these seem appropriate to me. People can raise JIRAs and do proposed updates on the TUSCANYWIKI space, once they've proven themselves we can vote them in as a website committer just like from code contributions. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting developer jira access to Amita Vadhavkar
+1 from me Yours, Mike. Luciano Resende wrote: Amita Vadhavkar has been helping DAS for couple months and recently also started to help on SDO and had contributed many patches. I'd like to give her developer access to JIRA so she can manage JIRAs with more flexibility, etc. Thoughts ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Result] was Re: [VOTE] Fuhwei Lwo for Tuscany Committer
Welcome Fuhwei ! Yours, Mike. kelvin goodson wrote: We now have sufficient IPMC votes (there were cast on the general list where notification of this vote was posted, see [1]) to close this vote and welcome Fuhwei as a Tuscany committer. Kelvin. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg14517.html On 28/06/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote: +1 from me, welcome Fuhwei. On 6/26/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > I'd like to propose Fuhwei Lwo as a Tuscany Committer. > > According to my gmail archive he has, since mid of 2006, posted 114 times > to > tusany-dev, 79 of those times resulting from interactions with JIRA issue > management. > > He has raised 34 JIRAs (see [1]) > > The gmail search -- "from:fuhwei [jira] Attachment:" shows > that > Fuhwei has attached around 27 patches to JIRAs. > > The JIRAs he raises, the comments he makes and the solutions he provides > demonstrate in depth knowledge of SDO and clearly he will be a strong > asset > for the community. > > Please vote to give Fuhwei this well deserved status > > Regards, Kelvin. > > [1] > > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&reporterSelect=specificuser&reporter=fuhwei&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StackOverflowException when mutual reference exist
Huang, Huang Kai wrote: I mean that composite A has a component which uses composite B as an implementation and that composite B has a component which uses composite A as an implementation . I think this use case is fairly common, eg. [Employee] has a property refer to [Company] and [Company] has a property refer to it's [Employee]s. And when these two java components are in different composites, I'll have to define mutual referenced composite files above. Aaargh - this is the case that I was worrying about. OK - what you need to understand here is that using a composite to implement a component within a higher level composite is *NOT* a reference property. Using something as an implementation is a STRUCTURAL relationship. It means that the implementation is "part of" the containing composite. Now if you view it that way, then it does *NOT* make sense for a Company to be "built from" employees and then for the employees to be "built from" a company. That is what your use case is like. It's OK for a "Company" component to have a reference to an "Employee" component - but a reference is not the implementation of a component - it is a dependency that one component has on another. Does that make sense? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Scott,
I think you ask a fair question here, which is definitely a question for
the Assembly spec working group to consider and answer.
Making it as succinct as I can, I think the issue is this:
For the interfaces at each end of a wire, when they are specified using
the same interface definition language, do they have to be identical, or
is it sufficient that they both map to the same WSDL?
It is clear in the case where the interface definition languages are
different, that the rule is to map to WSDL and then compare the WSDLs.
This is not stated for the case where the two ends of the wire use the
same interface definition language.
I can also see two cases to consider:
a) Where the interface is local
b) Where the interface is remotable
I believe that for local interfaces, only by using the same interface
definition language is it possible to have a local interface. In this
case, the rules are going to REQUIRE that the interfaces are identical.
Local in principle implies handing over of "native" data objects
between client and provider - ie Java objects in the case of Java
interface definitions. This can't be done if the object types don't
match exactly.
For remotable interfaces, they MUST be mappable to WSDL. So in the case
of wires connecting remotable interfaces, the rule is to map both ends
to WSDL and then do the comparison. Hence I think that in this case,
the Java form of the two interfaces does not have to match at all - as
long as the databinding takes care of mapping the Java interfaces to the
same WSDL, then we are good to go.
This is my interpretation - let's see what the other spec team people
think about it
Yours, Mike.
Scott Kurz wrote:
Mike,
I'd been steering the discussion towards how to avoid annotations since I
haven't been interested in the mixed cases (since I'm not sure who would
want to do that) and the last points we've been discussing relate to how to
do the Tuscany-specific introspection and DB setup properly.
So I personally don't see a need to input to the spec.
--
I'd like to use this opportunity to ask about a different point (but
related
to the subject heading of the JIRA).
(This is long because I fleshed out some examples)
I would be interested to hear your and others' opinions on the question:
how does the choice of intf at Assembly impact the PM?
(I think this question was touched on in the original exchange btw. Raymond
and Jim Marino but I'm not sure how it was resolved.)
To illustrate, suppose I have a WSDL which defines operation 'm1'
In MyIntf.wsdl:
http://pkg.my/v1";
xmlns:tns="http://pkg.my/v1"; ...>
...
...
...
I'm planning to use this MyIntf portType on an to type an
SCA service intf
But first, say I have a Java impl of this service intf:
MyImpl.java
@Service(some.pkg.MyIntf.class)
class MyImpl implements some.pkg.MyIntf {
void m1(my.pkg1.MyType) {
// .. impl ..
}
}
Suppose some.pkg.MyIntf is generated from WSDL per-JAXWS. Suppose that the
Java type
my.pkg1.MyType is mappable to the somens:MyType schema type.
Having set this up, I don't think there's any question that the the
some.pkg.MyIntf is wire-compatible
with WSDL interface: tns:MyIntf
Now, the question of whether this will work in Tuscany or not will
depend on
more info introspected
from the impl. For example if the impl uses a generated SDO of type
my.pkg1.MyType or a JAXB type
annotated to match somens:MyType, then this will be able to make it through
the Tuscany DB framework.
If my.pkg1.MyType matches a POJO or some other type, then whether it will
work depends on whether we
can construct the appropriate transformer chain or not.
If the component-service is configured in SCDL with:
http://pkg.my/v1#wsdl.interface(MyIntf)"/>
then there's no question the Java impl's Java service intf is compatible
with this WSDL intf. (My Java
interface's package doesn't matter since the SCA assembly spec clearly says
that mappability can be satisfied
in the interfaces have the same operations with the same types.
Now.. one way to phrase the core of the question I've been building up to
would be: are interfaces compatible merely by having "mappable" types
or do they have to be "the same"?
Sec. 1.6.4 of the Assembly spec seems to say both in a short span.
So, some examples:
With the same MyImpl.java annotated above with service intf:
@Service(some.pkg.MyIntf.class)
would the following Java interfaces be considered mappable if they were
placed on the component-level service in SCDL
via the corresponding element?
MyIntfSDO.java
void m1(DataObject)
MyIntf.java
void m1(my.pkg2.MyType) // MyType is identical but in a different
package
MyIntf.java
void m1(my.pkg2.MyTypeImpl) // where MyTypeImpl is a generated SDO
implementing MyType
Hopefully it's clear how these examples relate to my question: how d
Re: StackOverflowException when mutual reference exist
Huang, Can you clarify what you mean please? What configuration of composites are you using? Yours, Mike. Huang Kai wrote: I'm in the case 2. :( It's error-prone - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2007 11:11 PM Subject: Re: StackOverflowException when mutual reference exist On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Huang, I assume that by "reference" here, you mean a service reference? If that is so, it should work. If you mean that composite A has a component which uses composite B as an implementation and that composite B has a component which uses composite A as an implementation - then this IS an illegal cyclical usage and should generate an error. Yours, Mike. Huang Kai wrote: When CompositeA has reference to CompositeB while CompositeB also has reference back to CompositeA, CompositeBuilderImpl.build(composite) seems went into endless loop. I'm not very sure whether it's a bug or this kind of reference is illegal? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Mike For clarification. In the first case is the assumption that the application will ensure that messages do not pass round the loop forever. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL implementation: WSDL and BPEL resolving - FOUND YOUR PROBLEM
Matthieu,
Comments inline
Matthieu Riou wrote:
Hi guys,
I've done a few additional stuff on the BPEL implementation allowing a BPEL
file to be compiled by ODE upon deployment. The implementation is therefore
created and initialized with most of what would be needed by the runtime.
However there's still a couple of problems with resolution and finding my
way inside Tuscany code isn't that easy.
To resolve the WSDL implemented by the process I've been trying to go
through the resolution mechanism and declare the implementation I return in
the read() method of the processor as unresolved.
I've done the Spring implementation type which has some characteristics
similar to that of your BPEL implementation type.
Take a look at the implementation-spring module in Tuscany SCA. The
relevant file is SpringArtifactProcessor...
There read() is called and a SpringImplementation returned which is
unresolved (see line 139) and then resolve() is called later, resulting
in the Spring application context getting loaded and the Spring runtime
initialized.
PS You might like to rename "BPELImplementationProcessor" to
"BPELArtifactProcessor" to make it clearer what that class does - it
processes an element in the composite file (we
refer to that as the artifact, rather than the implementation.
However the resolve()
method is never called afterward and this results in a NullPointerException
in Tuscany as the InterfaceContract is never set. From what I could make
out
of the code, it seems that the resolution mechanism happens for Interface
processors but not of implementations, but I could be wrong.
Well, it definitely works for the Spring implementation, for sure. If
resolve is not being called, then there must be something odd about the
implementation object that you return.
AHA - yes there is something odd!! Go look at these lines in
BPELImplementationImpl:
public boolean isUnresolved() {
// The sample BPEL implementation is always resolved
return false;
}
...notice that is always returns "false" !!
So your implementation type always says that it is resolved. No wonder
resolve() does not get called. Change the code here to return the value
of some boolean field which gets set by setUnresolved() -
setUnresolved() also does nothing at the moment
I've created a patch that adds the BPEL compilation and demonstrates the
problem using the test case. Please have a look at
BPELImplementationProcessor, you'll see how the implementation is built.
You'll also see that the BPEL file from now is directly loaded using an
additional "file" attribute. Ideally that should go as well to use the same
type of resolving as for the WSDL (when it will work).
Some help regarding this would be definitely welcome...
Thanks,
Matthieu
Yours, Mike.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pruning committers and pmc members
Dims, Davanum Srinivas wrote: Folks, Believe it or not! we have 230 people who have karma to our svn: https://svn.apache.org/repos/asf/webservices/ Out of these only about 74 people have made commits in the last 1 year. You can get this info by using the svn log: svn log -v --revision 2006-07-05:HEAD https://svn.apache.org/repos/asf/webservices/ I'd like to start a process of pruning both the committer list and the pmc members list. As am sure some of the pmc members have not been active recently either as i alluded to you in the prev email about the board report. Here's something i came up with. Basically i will add a text file in https://svn.apache.org/repos/asf/webservices/admin which will have the names of all the committers and an option right next to their name with Y/N and question being would you like to keep your commit rights. Example. dims [Y/N] I can pre-fill this to Y for everyone who have made commits in the last 1 year to reduce work for already active people. At the end of say 2 weeks from kicking off the process, we will collect the final tally and prune the svn karma to those who chose to edit the file. If someone missed the deadline or want to get back karma say in a couple of months, they can send a quick email to the pmc (private AT ws.apache.org) and one of us can add it right back. How about we use the same process for PMC members too? I can add another file for pmc members and here i will not prefill anyones option. All PMC members have to edit the file and modify the option next to their name. At the end, same 2 weeks, we can declare those who did not choose to be active as Emeritus. For PMC members, there is a higher threshold, if one of the Emeritus members want to get back into the game, they will have to drop an email and we will hold a vote. This is because, we need to notify the board for *every* pmc member change and there are legal implications and a higher threshold. Sounds good? comments? thanks, dims Sounds fine to me. I don't see the file you point to in https://svn.apache.org/repos/asf/webservices/admin ...did I miss something or is it simply not ready yet? Yours, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StackOverflowException when mutual reference exist
Huang, I assume that by "reference" here, you mean a service reference? If that is so, it should work. If you mean that composite A has a component which uses composite B as an implementation and that composite B has a component which uses composite A as an implementation - then this IS an illegal cyclical usage and should generate an error. Yours, Mike. Huang Kai wrote: When CompositeA has reference to CompositeB while CompositeB also has reference back to CompositeA, CompositeBuilderImpl.build(composite) seems went into endless loop. I'm not very sure whether it's a bug or this kind of reference is illegal? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
Folks, OK, finally, I bite ;-) The question for me is whether we need the SCA (Java) spec to define some standard metadata (typically annotations) for databindings of services & references. I make the assumption that for much of the time, it is possible to work out the required databinding simply by inspection of the types of the parameters involved. If you find an SDO object, if you find a JAXB object, etc. So is the real issue the case where mixed types of data objects turn up? Or are there ambiguous cases where you can't tell what the kind of object is? I suppose that we can take two views of cases like these: a) Don't go there, it's not valid. b) OK, annotate your code enough to tell us exactly what you expect to happen. If we want to go down the second path, then I'm happy to carry back requirements to the SCA Java WG, but I'd really like an appreciation of just how common this case is likely to be. Views please Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make sca-api.jar an OSGi bundle
Venkat, I'm in favour of adding OSGi metadata to relevant jars to enable them to act as OSGi bundles. I think that OSGi is in a different space than "other runtimes" and that supporting it is a good idea. Other comments inline... Yours, Mike Venkata Krishnan wrote: Hi, This seems ok since you say it does not have side effects for other consumers. However, I wonder if we can keep doing this for accomodating other runtimes as well - am not sure what the others might want or if they'd need something not as simple as this - just postulating here ;-). OSGi is less "another runtime" and more "a whole class of runtimes", so in that sense it is special. OSGi is a framework for organizing runtimes into logical chunks. Many runtimes use OSGi - the most famous being Eclipse. I think that we should make it easy for Tuscany SCA (and SDO for that matter) to fit into a runtime that is using OSGi. To do that ideally requires us to add some OSGi metadata to relevant jar files. Or, seeing it from the other side I wonder if it would be ok to consider specific inclusions in OSGi bundles to facilitate their handling in a SCA runtime. This is looking at it the other way around. I believe that this is the work that Rajini and others are already doing in building an for Tuscany, to allow stuff built using OSGi to work cleanly within Tuscany. So, from what I am able to comprehend, I'd prefer to avoid this tie in. Maybe we should also hear what others have to say. It is no tie-in. Adding OSGi metadata does not make any of our JARs unusable by anyone else and it does not force the use of OSGi - and the handling of the OSGi metadata in the build process can be pretty simple, I believe. There is a whole separate question about whether we should consider building the whole Tuscany SCA runtime using OSGi. There are merits to that, but also potential downsides - however, we can have a completely separate debate about that some other time, since it has nothing to do with Rajini's current proposal. Thanks - Venkat On 7/6/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: Hello, Could we convert sca-api.jar to an OSGi bundle so that bundles used by the OSGi implementation type can import SCA annotations and interfaces? This may be already being addressed in the other OSGi related work, but the change is simple and will enable the support for SCA annotations in OSGi bundles to progress. Converting sca-api.jar to an OSGi bundle would just need the addition of a few entries in the manifest file for the jar, and will not affect any other modules using the jar file as a regular jar. Thank you... Regards, Rajini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The complete patch for TUSCANY-1341 is available
Folks, I tend to favour this more conservative approach. There may be a problem longer term in explaining the interfaces to writers of new binding types and implementation types, but the mess caused to existing implementation types and existing binding types by breaking changes in the SPI is not worth it, based on my experiences. My 2 cents, Mike. ant elder wrote: On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote: 1. Not including the change to remove the redundant isCallback parameter from ReferenceBindingProvider.createInvoker() doesn't cause any significant problems in the core. The core can always pass the meaningless extra parameter, and the providers can always ignore it. This does incur the collateral rework costs that I mentioned above for when we get around to cleaning this one up. +1, this sounds a good approach to me 2. Not including the supportsAsyncOneWayInvocation() methods on ReferenceBindingProvider and ServiceBindingProvider presents a bit more of a challenge. One possibility is to create a new marker interface that can be implemented by providers that support asynchronous one-way invocation. The core could test for this marker interface and omit the thread switch if the provider implements it. I'm not really convinced that this is cleaner (it's probably a bit more tricky to explain than just having methods for this as we do everywhere else in the SPI), but it would get around the need for a breaking SPI change now. What do people think about this approach? +1, I like it a lot 3. Not including the createCallbackInvoker() method on ServiceBindingProvider. seems at first sight to make it impossible for callbacks to work. But there is (as always with software) another way. We could introduce a new interface ServiceBindingCallbackProvider that extends ServiceBindingProvider and adds the createCallbackInvoker() method. Providers that support callbacks would implement this interface, and providers that don't support callbacks could continue to implement ServiceBindingProvider. Again, this seems slightly tricky but it would work and it wouldn't need a breaking SPI change. +1 again Now I'll circle back to 1 again. The proposal for 3 has inspired me to imagine a new interface that just contains the new method signature for createInvoker(). New providers can implement this interface and the new signature, and old providers can continue with the old signature, with the core being smart enough to understand both forms and call the signature that is available. Another +1 My opinion is that the long term solution is likely to be the one I have currently implemented, so the work to change other affected code will need to be done anyway at some point. I also agree the end result is likely to be similar but IMHO the benefits of keeping things separate and stable for the time being far out way the extra work of at some point cleaning up all the SPIs (which we're going to have to do anyway). ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509460 ] Mike Edwards commented on TUSCANY-1389: --- I think that the right approach here is to use the XSDs for SCA. Eclipse XML tooling is certainly capable of using XSDs as well as DTDs to describe to structure of XML documents. The SCA XSDs are freely available at: http://www.osoa.org/xmlns/sca/1.0 I propose one additional step which will help in handling the SCA samples - that each composite file in the samples has an xsi:location attribute added to it as follows: xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd " This should allow any context aware XML editor to find the SCA XSDs and use them for validation and editing assist. Anyone who wants to workffline will need to install local copies of the XSDs on their machine and adjust the xsi:location target value. > published DTD for composite XML Schema needed/useful > > > Key: TUSCANY-1389 > URL: https://issues.apache.org/jira/browse/TUSCANY-1389 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA > Samples >Affects Versions: Java-SCA-0.90 > Environment: java >Reporter: James Tomkinson >Priority: Minor > Attachments: addattributes_knownfromDTD.jpg, > addchild_knownfromDTD.jpg, openwithxmleditor.jpg > > > Samples should supply a DOCTYPE in *.composite xml files, that points to a > stored DTD, so that XML editing tools can be used to create/edit/validate XML > schema. This will enhance productivity/accuracy. > Example for Hibernate: >"-//Hibernate/Hibernate Configuration DTD 3.0//EN" > > "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";> -- 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: How are we going to use the Tuscany Wiki space?
Luciano, How does this compare with the existing structure? This seems to approach things from a "Java" perspective rather than an "SCA" / "SDO" perspective - is that right? It might be useful to create an example of what you mean in the TuscanyWiki psace... Yours, Mike. Luciano Resende wrote: I'd like to propose using a structure similar to the one described below to group documents together and make it easier to find related information. It's probably good not to have very deep hierarchy, and maybe start grouping things on a specific level via page name (e.g distribution-import-export, distribution-model, etc) SCA Java Project | |--- SCA related Documents SDO Java Project | |--- SDO related Documents DAS Java Project | |--- DAS related Documents Infrastructure | |--- Infra related Documents such as builds, sync, etc Website | |--- Website related documents and old website copy Thoughts ? On 6/30/07, Simon Laws <[EMAIL PROTECTED]> wrote: On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > I'd like to retain the copied pages from the Tuscany web site. As Venkat > said, this makes it easy for non-committers to develop and preview > proposed > updates to the Web site. I agree that it would be good to create a new > front page for the Wiki, with the copied Web site home page >http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Home > linked from the TUSCANYWIKI front page. > >Simon > > Simon Laws wrote: > > > I agree. Looking at it now it is confusing with the complete copy of the > > web > > site material presented on the front page. It's not clear where the > > definitive source of this material is. > > > > +1 to the proposal for changing the front page of TUSCANYWIKI. I would > have > > thought we can just start with a subpage of TUSCANYWIKI for "main site > > pages > > in preparation". Everthing else is wiki content with an organization of > our > > choosing. > > > > Regards > > > > Simon > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] I've had a go at reorganizing the front page of the wiki. But it's a wiki so if you don't like it Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test - please ignore
test - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: binding element cardinality - SCA 1.0 spec typo?
Jacek, It's fine to post stuff about the SCA and SDO specifications here on the Tuscany mailing list. There is also a feedback page on www,osoa.org (the site for the specifications themselves) here: http://www.osoa.org/display/Main/Feedback+on+SCA+Specifications Regarding your comment here - yes, this is a bug in the spec. I will add it to the Errata list for the Assembly spec here: http://www.osoa.org/display/Main/Errata+for+Assembly+Model+V1.00 The SCA XSDs (lines 3107 onwards) are correct - they show that zero or more bindings are allowed. The spec text and the associated XSD snippet are incorrect. Yours, Mike. Jacek Laskowski wrote: Hi, (I hope it's allowed to post emails about sca spec here and it won't be considered as spam) While reading the SCA spec I came across the following sentences - page 13: 180 A service element has one or more binding elements as children. If no bindings are specified, 181 then the bindings specified for the service by the implementation are in effect. Is that a mistake where it's written that a service element has one or more binding elements as opposed to the following sentence that starts with "If no bindings..."? Where should I report it? Jacek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful - SUGGESTION
James, I'm not sure which XML tools that you are using, but I'll give you my experiences and make a suggestion. I use Eclipse and for XML and XSD editing I've installed the Eclipse Web Tools Project, which you can find here: http://www.eclipse.org/webtools/main.php The XML editor in WTP supports creation and editing of XML files with assist and validation based either on the use of DTD or on the use of XSD files to define the structure of the XML documents. Here is a quick and incomplete sample of an SCA composite file which I built using the editor: http://tempuri.org"; xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 ../xsds/sca-core.xsd "> This had validation and assist working for me. Note the schemaLocation attribute in the composite element - this points at the xsds for SCA. In my case I had a local copy in my project, hence the "../xsds/..." location value. The XSDs are actually also available online in the place implied by their namespace: http://www.osoa.org/xmlns/sca/1.0/... So, I hope that by providing a correct schemaLocation attribute in your composite files you should be able to get the behaviour you're after. Now, I suppose the next thought is to ensure a valid schemaLocation attribute in our sample files xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd"; will do the trick I think. What do other folks think? Yours, Mike. James wrote: thanks for your reply. i adding information about Eclipse use of DTD. if similar for XSD then that's fine (i'm not an expert on this). see screenshots added to this issue. At 09:26 AM 6/27/2007, you wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508537 ] Mike Edwards commented on TUSCANY-1389: --- James, Does it have to be a DTD - or will an XSD be sufficient to meet your requirements? I have a particular dislike of DTDs born of having to deal with them in relation to SGML documents "back in the old days". There are plenty of tools that can work with XSDs and use them for validation. > published DTD for composite XML Schema needed/useful > > > Key: TUSCANY-1389 > URL: https://issues.apache.org/jira/browse/TUSCANY-1389 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA Samples >Affects Versions: Java-SCA-0.90 > Environment: java >Reporter: James Tomkinson >Priority: Minor > > Samples should supply a DOCTYPE in *.composite xml files, that points to a stored DTD, so that XML editing tools can be used to create/edit/validate XML schema. This will enhance productivity/accuracy. > Example for Hibernate: >"-//Hibernate/Hibernate Configuration DTD 3.0//EN" > "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";> -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bigger fonts on Tuscany web site? - not so easy
Folks, This turns out to be surprisingly difficult to do - Confluence Wiki has no easy way to change the font size either of the whole site or of one space. It can't be done at all just for one page... There is some grousing about this on the Confluence forum at Atlassian (who write Confluence). The best that can be done is to mess about with css stylesheets for the Tuscany spaces. Before we go down that gruesome road, I'd like to see if people think this is really worthwhile. Yours, Mike. Simon Nash wrote: The current fonts look good on my screen. Would it be possible to put a demo page up on TUSCANYWIKI showing how a larger font would look? Simon Jean-Sebastien Delfino wrote: Is it just my eyes or the fonts on my Linux system? but I find the fonts on our Web site really small. What do people think about using bigger fonts? By the way could we change the colors in our template to be a little greener? just kidding :) but I'm serious about the fonts... - 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] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful
[ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508537 ] Mike Edwards commented on TUSCANY-1389: --- James, Does it have to be a DTD - or will an XSD be sufficient to meet your requirements? I have a particular dislike of DTDs born of having to deal with them in relation to SGML documents "back in the old days". There are plenty of tools that can work with XSDs and use them for validation. > published DTD for composite XML Schema needed/useful > > > Key: TUSCANY-1389 > URL: https://issues.apache.org/jira/browse/TUSCANY-1389 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA > Samples >Affects Versions: Java-SCA-0.90 > Environment: java >Reporter: James Tomkinson >Priority: Minor > > Samples should supply a DOCTYPE in *.composite xml files, that points to a > stored DTD, so that XML editing tools can be used to create/edit/validate XML > schema. This will enhance productivity/accuracy. > Example for Hibernate: >"-//Hibernate/Hibernate Configuration DTD 3.0//EN" > > "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";> -- 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] Commented: (TUSCANY-1377) Conversational PM- HTTP Session persistence
[ https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508486 ] Mike Edwards commented on TUSCANY-1377: --- There is a mixture of 2 things here, as described in Sebastien's last comment: 1) Handling of Scope for components (he mentions implementation.java, which is fine) 2) Dealing with conversational sessions on the HTTP binding These two are NOT directly related. You can do one without the other. I'd suggest sorting out the HTTP binding first - only once there is a conversation going on between 2 components over the wire does it become useful to implement the Scope attribute on a component. > Conversational PM- HTTP Session persistence > --- > > Key: TUSCANY-1377 > URL: https://issues.apache.org/jira/browse/TUSCANY-1377 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-Next >Reporter: ant elder > Fix For: Java-SCA-Next > > > Implement conversational PM- HTTP Session persistence -- 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: Finding the .componentType file
Jean-Sebastien Delfino wrote: Nobody picked up my earlier post to this thread, I thought that my concrete examples were interesting though :) so I'll repeat a concrete example again here: componentType file: calculator/CalculatorImpl.componentType - The relationship is obvious to a human - There is no SCDL attribute pointing to the componentType - The relationship class name -> .componentType file location is specific to the Java implementation type. IMHO you need implementation specific code to derive the .componentType file location from the attributes of the . I think that I'm agreeing with you very strongly - I just said it a different way. The C++ example I gave was a more stark example of the problem of why there is no direct relationship between component and componentType file independent from the implementation type itself. You are right - the SCDL does not point to the componentType file. If we had called componentType files "implementationInfo" files instead, this would perhaps have made the situation clearer - that componentType side files are there to provide extra information about an implementation for those situations where you can't get the information directly from the implementation (ie via introspection). Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Fuhwei Lwo for Tuscany Committer
+1 from me Yours, Mike. kelvin goodson wrote: I'd like to propose Fuhwei Lwo as a Tuscany Committer. According to my gmail archive he has, since mid of 2006, posted 114 times to tusany-dev, 79 of those times resulting from interactions with JIRA issue management. He has raised 34 JIRAs (see [1]) The gmail search -- "from:fuhwei [jira] Attachment:" shows that Fuhwei has attached around 27 patches to JIRAs. The JIRAs he raises, the comments he makes and the solutions he provides demonstrate in depth knowledge of SDO and clearly he will be a strong asset for the community. Please vote to give Fuhwei this well deserved status Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&reporterSelect=specificuser&reporter=fuhwei&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Old tuscany website
Adriano, There is something I dont get here. When I point my browser at the URL you give here, I get a fine Tuscany home-page based on the Tuscany Wiki material. So in what way is it not "active"?? Just to be sure you're seeing what I'm seeing, I've attached an image of what I get in my browser for that URL... Yours, Mike. Adriano Crestani wrote: Should old tuscany website url be activated? http://incubator.apache.org/tuscany/ Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki problem
Adriano, You need to answer my question about why you expect to see *ANYTHING* at the URL you are using, whether you are logged in or not. The URLs in my note are the places I'd expect anyone to look for Tuscany stuff. Yours, Mike. Adriano Crestani wrote: But Luciano, I'm not being able even to read the image when I'm logged out, the image is just not displayed. As far as I know the wiki contents should be seen for anyone, shouldn't it? Regards, Adriano Crestani On 6/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote: If I understood your question right... the TUSCANY wiki store our website contents, and is only editable by Tuscany committers. When you are logged out, you won't be recognized as one, and therefore won't be able to edit any contents. As for the URL you showed as an example, I have similar question as Mike :) Also, as for contents, we should maintain the website structure and add things in the "DAS" section of the website. On 6/22/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > Adriano, > > I'm puzzled by the URL that you are using here. > > When editing the Wiki, I'd expect you to be somewhere like > here: > > http://cwiki.apache.org/confluence/display/TUSCANY/DAS+RDB+Menu > > When viewing the Tuscany website I'd expect you to be somewhere like here: > > http://incubator.apache.org/tuscany/das-overview.html > > What did you expect to find at the URL below. > > > Yours, Mike. > > > Adriano Crestani wrote: > > I'm not being able to access the > > http://cwiki.apache.org/TUSCANY/rdb-das-class-diagram.html image when I'm > > logged out, only when I'm logged in. Does anybody know why? > > > > Adriano Crestani > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ SDO spec compliance/portability: SDORuntimeException
Pete, Cattle-prod of high voltage required for the spec team then. ;-) Yours, Mike. Pete Robbins wrote: I agree Mike but the SDO spec does not currently define a set of headers that are compilable so adding in things like constructors/destructors is necessary. When we have a set of headers from the spec group we should use those to replace the current Tuscany headers. Until then we should aim to get them as close as possible. Cheers, On 22/06/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, My 10 cents is that it is not right to add methods to the spec API classes. My view would be that compliance would require spec-defined classes to provide the spec, the whole spec and nothing but the spec. This is certainly the approach to compliance taken for most Java APIs. It's OK to have officially defined extension points - the classic one is the interface / implementation split - but in general, if some object is supposed to be an implementation of the spec, then that is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. Pete Robbins wrote: > Michael, > > An interesting set of questions! I'm not convinced that adding methods to > the spec api classes is a compliance issue (in fact it may be impossible to > implement without modifying the spec apis ... constructors etc.) but it > could be a portability issue if it is not clear that the methods are > implementation specific. > - 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: Wiki problem
Adriano, I'm puzzled by the URL that you are using here. When editing the Wiki, I'd expect you to be somewhere like here: http://cwiki.apache.org/confluence/display/TUSCANY/DAS+RDB+Menu When viewing the Tuscany website I'd expect you to be somewhere like here: http://incubator.apache.org/tuscany/das-overview.html What did you expect to find at the URL below. Yours, Mike. Adriano Crestani wrote: I'm not being able to access the http://cwiki.apache.org/TUSCANY/rdb-das-class-diagram.html image when I'm logged out, only when I'm logged in. Does anybody know why? Adriano Crestani - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ SDO spec compliance/portability: SDORuntimeException
Folks, My 10 cents is that it is not right to add methods to the spec API classes. My view would be that compliance would require spec-defined classes to provide the spec, the whole spec and nothing but the spec. This is certainly the approach to compliance taken for most Java APIs. It's OK to have officially defined extension points - the classic one is the interface / implementation split - but in general, if some object is supposed to be an implementation of the spec, then that is all it should be and implementation details should not affect using applications. Compliance is still much of a blank sheet for both SDO and SCA - but I will certainly argue along these lines when compliance becomes a significant matter in the OASIS TCs that are about to form Yours, Mike. Pete Robbins wrote: Michael, An interesting set of questions! I'm not convinced that adding methods to the spec api classes is a compliance issue (in fact it may be impossible to implement without modifying the spec apis ... constructors etc.) but it could be a portability issue if it is not clear that the methods are implementation specific. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finding the .componentType file
Ant, In general, I would agree that there should be a simple and obvious relationship between implementation artifact and componentType file. However, consider the case of languages like C or C++ where multiple implementations are bundled into a DLL. The runtime file is the DLL, but there must be multiple componentType files. So now, what is the relationship between them In these more complex cases, the implementation type defines the relationship. Yours, Mike. ant elder wrote: On 6/18/07, Mike Edwards <[EMAIL PROTECTED]> wrote: How does that fit with the spec saying - ""A component type file has the > same name as the implementation file but has the extension > ".componentType"" > ? I'm looking for a way to make the default case easy, it doesn't have to > deal with every edge case. Unfortunately, this is no edge case. There is no reason to expect the component name to be even close to the implementation name. AFAICT, unless there's an attribute in the SCDL to explicitly point to it there has to be a way to find these things programatically, and for humans to understand whats going on in a contribution it must be reasonably obvious which .componentType side file is associated with which implementation just by eyeballing the files. Otherwise, what does this line in the spec mean: 'A component type file has the same name as the implementation file but has the extension ".componentType"' ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finding the .componentType file
Ant, Yes, sometimes the terminology can get confusing. The component name may be nothing like the implementation name How does that fit with the spec saying - ""A component type file has the same name as the implementation file but has the extension ".componentType"" ? I'm looking for a way to make the default case easy, it doesn't have to deal with every edge case. Unfortunately, this is no edge case. There is no reason to expect the component name to be even close to the implementation name. The componentType file is really to be thought of as an extension of the implementation for those (hopefully few) cases where introspection of the implementation cannot provide the required information. Maybe "implementationType" would have been be a better name :-) One name that we dearly wanted for "componentType" was "implementationInfo". We tried hard to get that name but failed. That alternative makes it clearer that the file contains metadata about the implementation. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finding the .componentType file
Ant, The idea of using the component name is completely wrong and unacceptable, I'm afraid. The component name may be nothing like the implementation name - and an implementation can be used multiple times by different components. The componentType file is really to be thought of as an extension of the implementation for those (hopefully few) cases where introspection of the implementation cannot provide the required information. My suggestion is that the SPI should put the burden on the implementation module - for example a special method on the xxxImplementation class with a name like "locateComponentTypeFile". Actual loading of the componenttype file can be generic, but finding the file is definitely a job for the implementation-handling code. PS I suspect that it may be wise to allow the implementation to hook out the loading of the componentType file. With extensibility allowed, the componentType file might conceivably contain extra information in the case of some implementation types Yours, Mike. ant elder wrote: I'm struggling with how to define and locate the .componentType side file in the implementation SPI. The assembly spec says: "A component type file has the same name as the implementation file but has the extension ".componentType"...The location of the component type file depends on the type of the component implementation..." (page 13 line 445). The problem is "the implementation file" is not specific enough and there isn't a standard way for the runtime to know which implementation attribute is the "implementation file". Eg, for implementation.java its the 'class' attribute, for implentation.script its the 'script' attribute, for implementation.das its the 'config' attribute etc. Any one have any ideas on how to do this? Would it be be terribly non-compliant if the default used by the runtime was "A component type file has the same name as the _component_ with the extension ".componentType"? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1152) Support Spring beans as eager-init singletons with references to SCA composite references
[ https://issues.apache.org/jira/browse/TUSCANY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505192 ] Mike Edwards commented on TUSCANY-1152: --- The only information about this issue is the title, which is a bit thin! Having implemented the Spring Implementation support for the new core runtime, I'm having trouble understanding why this is required: 1) Why Spring beans need to be eager-init. In fact, in the current implementation, lazy initialization is almost forced due to timing issues relating to the instantiation of Spring Beans vs the existence of the wire configuration for references that they make. 2) Why singletons? This I really don't understand. Seems counter-intuitive to me. 3) References to SCA Composite references. Already supported as standard in the current implementation. So, unless someone can come up with a detailed explanation of the requirements behind this Issue, I propose to close it as "won't fix" since none of the items seem to make sense to me. Have I missed something here? > Support Spring beans as eager-init singletons with references to SCA > composite references > - > > Key: TUSCANY-1152 > URL: https://issues.apache.org/jira/browse/TUSCANY-1152 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Spring Implementation Extension >Affects Versions: Java-SCA-Next > Reporter: Jim Marino >Assignee: Mike Edwards > Fix For: Java-SCA-Next > > -- 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]
How are we going to use the Tuscany Wiki space?
Folks, I'm a bit confused (nothing out of the ordinary there then!) about how we intend to use the new Tuscany Wiki space. So, the Apache Tuscany space is the material which makes up the external Tuscany website. I understand our desire to control the update of material there - hence there is a restricted list of people who can edit pages there. So, I thought, perhaps wrongly, that the Tuscany Wiki space was created to be a space "open to all" where any kind of material can be placed by anyone. This includes different sorts of stuff, I think: a) Material that is being prepared for the Tuscany website, so that it can be checked out before it goes live. b) Discussion and similar material that is useful to help the work within the Tuscany community, but which may never reach the public website, such as design ideas related to discussions in the mailing list (good example is the stuff Simon Laws has created relating to distributed runtime). Currently, the material in the Tuscany Wiki space is simply a mirror of the Apache Tuscany space. I don't think that this is right. First, simply repeating everything that is in the main space is confusing at best. Worse, there needs to be some explanation of the use of the space and some specific navigation available, such as where to create new material and, for material intended for the main Tuscany website, some explanation of the process. I'd like folks views on this. If you agree with me, then I suggest that we should: a) Rewrite the front page of the Tuscany Wiki to explain its purpose b) Remove the Tuscany Wiki pages that are mere copies of pages on the main Wiki and adjust the navigation to separate out discussion pages from pages being prepared for the main site c) Provide an explanation of how to write pages intended for the main Tuscany website and the process for getting them there... Thoughts? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Access issues ? **HELP**
Venkat, Yes, it works just fine. Time to start helping...! Mike. Venkata Krishnan wrote: HI Mike, I have already added you id as 'confluence administrator' which I've mentioned on another thread on the ML. Could you please try and let me know if it works. Thanks. - Venkat On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Folks, So what's with the Edit access to the Tuscany Wiki?? I don't seem to have edit access at the moment, despite being a committer. Who has admin rights for the Wiki? Can one of the admins please grant me edit access, please? Also, I know that there was a discussion about broadening the admin access for the Wiki. Has anything been done about that? My offer to play admin for the Tuscany Wiki remains open - I have plenty of experience based on my ownership of the www.osoa.org Wiki, which is also based on Confluence. Yours, Mike. Simon Laws wrote: > So I expect this is just the product of edit access being restricted to > committers. Please comment on Luciano's post here [1] so that a new space > can be provisioned (assuming that this is what is agreed) ASAP. > > Simon > > [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18622.html > - 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: Website - Consistent navigation menus
Venkat, Many thanks, Mike. Venkata Krishnan wrote: Hi Mike, I have added your id in as 'confluence-administrators'. - Venkat On 6/13/07, Mike Edwards <[EMAIL PROTECTED]> wrote: Luciano, Only just spotted your request in the emails My user ID is edwardsmj Do I need to send this directly to infra, or will you handle it? Yours, Mike. Luciano Resende wrote: > Venkat, Mike, infra is asking for your confluence user ids, could you > please provide this info. > > On 6/8/07, Simon Laws <[EMAIL PROTECTED]> wrote: > >> Conversation seems to have stopped so, from the previous comments... >> >> * Confluence admins: >> >> Venkat, Luciano, Mike Edwards [1] have been proposed to cover the >> timezones >> we operate in. Venkat are you progressing this? >> >> * http://cwiki.apache.org/confluence/display/TUSCANY space access: >> >> As this is now feeding our main (http://incubator.apache.org/tuscany/) >> website we have been advised to restrict access to committers to >> prevent our >> shop front acquiring dubious content. I have removed "create" access from >> confluence users as I think we have been sailing close to the wind on >> this >> and it would be a shame to have our web site messed up, particularly as >> we've recently put out releases and we hope people are looking at them. >> >> There are alternative approaches to this blanket change, for example, >> we may >> be able to mark all of the web site pages in the /TUSCANY spaces as >> restricted but this would take some effort and complicate the management >> task We could also stop the automatic generation of the site and do it on >> demand manually but the idea of linking up the wiki to generate the >> web site >> was to avoid this. >> >> The main option that is on the table is to go with the committer only >> access >> to the TUSCANY space and create other spaces for whatever else we >> need, for >> example, a generally accessible wiki. Luciano has started a conversation >> about this [2] but I don't see much feedback. If you feel strongly can >> you >> go and comment so that we can move this forward quickly now we are >> restricting create access to /TUSCANY >> >> * Contributions to the web site >> >> We need to describe a mechanism where non-committers can contribute >> content >> to the web site. Looking at the comments here it seems that this will >> have >> to be through attaching text, cwiki markup or whatever other resources >> are >> required (png, jpg etc) to JIRA so that a committer can update the site. >> Logically this is no different from the situation we had when the site >> was >> maintained out of svn except of course that we could use diffs then. >> >> Regards >> >> Simon >> >> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18665.html >> [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18641.html >> > > - 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: IDE-specific files in svn
Frank, I'm of the opinion that anything that makes it easier for developers to get to grips with our stuff, the better. Personally, having to to create all the Eclipse stuff has been a pain, so doing this would save me time and effort. I agree with your sentiment that if others want to add features for other IDE's then that should be OK too. Yours, Mike. Frank Budinsky wrote: Hi, I remember about a year ago discussing whether or not it is acceptable/appropriate to check-in IDE specific files (e.g., Eclipse .project files) into svn, and we decided to not do it. Does anyone remember if this was really an Apache policy, or just a decision we made for Tuscany? If the latter, I wonder if we should reconsider. Personally, I think it would be very convenient if we had the Eclipse .project and .classfile in the projects, so that people could just check out Tuscany projects directly into Eclipse. For people not using Eclipse, having these superfluous files around really doesn't seem like a big deal. I also wouldn't mind if someone wants to check-in other IDE (e.g. IDEA) files that Eclipse users (like me) would just ignore. What do others think about this? Thanks, Frank. - 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: Website - Consistent navigation menus
Luciano, Only just spotted your request in the emails My user ID is edwardsmj Do I need to send this directly to infra, or will you handle it? Yours, Mike. Luciano Resende wrote: Venkat, Mike, infra is asking for your confluence user ids, could you please provide this info. On 6/8/07, Simon Laws <[EMAIL PROTECTED]> wrote: Conversation seems to have stopped so, from the previous comments... * Confluence admins: Venkat, Luciano, Mike Edwards [1] have been proposed to cover the timezones we operate in. Venkat are you progressing this? * http://cwiki.apache.org/confluence/display/TUSCANY space access: As this is now feeding our main (http://incubator.apache.org/tuscany/) website we have been advised to restrict access to committers to prevent our shop front acquiring dubious content. I have removed "create" access from confluence users as I think we have been sailing close to the wind on this and it would be a shame to have our web site messed up, particularly as we've recently put out releases and we hope people are looking at them. There are alternative approaches to this blanket change, for example, we may be able to mark all of the web site pages in the /TUSCANY spaces as restricted but this would take some effort and complicate the management task We could also stop the automatic generation of the site and do it on demand manually but the idea of linking up the wiki to generate the web site was to avoid this. The main option that is on the table is to go with the committer only access to the TUSCANY space and create other spaces for whatever else we need, for example, a generally accessible wiki. Luciano has started a conversation about this [2] but I don't see much feedback. If you feel strongly can you go and comment so that we can move this forward quickly now we are restricting create access to /TUSCANY * Contributions to the web site We need to describe a mechanism where non-committers can contribute content to the web site. Looking at the comments here it seems that this will have to be through attaching text, cwiki markup or whatever other resources are required (png, jpg etc) to JIRA so that a committer can update the site. Logically this is no different from the situation we had when the site was maintained out of svn except of course that we could use diffs then. Regards Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18665.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18641.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany wiki strategy, was :Re: Website - Consistent navigation menus
Venkat, +1 from me. How to migrate content? I assume that you mean how do we control the process? The steps in actually moving content are reasonably straightforward - but the process for deciding to do it must mirror that for placing code into trunk, as mentioned on some other emails... Yours, Mike. Venkata Krishnan wrote: Hi, I have the admin access now. I am able to see the 'Create Space' option on the dashboard now. Before I go ahead let me conform the following - We are going to create a space named 'Tuscany Wiki' with key 'TUSCANYWIKI' - All contents of the present wiki space 'TUSCANY' will be copied over to this new space - We will disable the html autoexport for TUSCANYWIKI as we really don't need this. - TUSCANYWIKI will be open to all confluence users. Please let me know if any of you have concerns about all of this. Also, are we clear about how we are going to migrate content submitted on TUSCANYWIKI over to TUSCANY? Thanks - Venkat On 6/12/07, Simon Laws <[EMAIL PROTECTED]> wrote: Ok, thanks Venkat for looking into this. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki Access issues ? **HELP**
Folks, So what's with the Edit access to the Tuscany Wiki?? I don't seem to have edit access at the moment, despite being a committer. Who has admin rights for the Wiki? Can one of the admins please grant me edit access, please? Also, I know that there was a discussion about broadening the admin access for the Wiki. Has anything been done about that? My offer to play admin for the Tuscany Wiki remains open - I have plenty of experience based on my ownership of the www.osoa.org Wiki, which is also based on Confluence. Yours, Mike. Simon Laws wrote: So I expect this is just the product of edit access being restricted to committers. Please comment on Luciano's post here [1] so that a new space can be provisioned (assuming that this is what is agreed) ASAP. Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18622.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spring Implementation - ready for primetime....
Folks, I think that the Spring Implementation is now in reasonable shape and is capable of being added to the main trunk build. The basic function is there, supporting Services, References and Properties. Advanced stuff like scoped behaviour of components will need extra work. More test cases would be a good idea too. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An observation about the current Contribution handling code
Jean-Sebastien, I've replied separately to your referenced note. My suggestion is that resolution should be split from loading. Resolution should take place in a cascade from the composites which are at domain level, in response to explicit references discovered there. Only entities in the actually deployed hierarchy will get resolved. Mere presence of some entity in a contribution should be of no significance for resolution. The problem today is that discovery and resolution are tied together in the code. This needs to look ahead to the point where specific entities in the hierarchy of composition are not destined for the runtime node that is performing the resolution. Yours, Mike. Jean-Sebastien Delfino wrote: [snip] Mike Edwards wrote: Whether resolution occurs for all the resources simply depends on whether there are resolvers for each type of resource. +1 for improving this, did you see what I proposed in [1], and does it make sense to you? Do you have any suggestions on how to implement this lazy loading + resolution? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18684.html Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lazy loading and resolution of SCA composites, was: An observation about the current Contribution handling code
Jean-Sebastien, Comments inline... Jean-Sebastien Delfino wrote: Mike, Good timing, as I am actually starting to work on some lazy + incremental loading and resolution of SCA assemblies. I had the following in mind: step 1: - change the CompositeProcessor to not resolve its references to others until it's actually referenced by another composite (through an or an ) or included in the domain as a deployable. Yes, this is an essential first step. Resolution should cascade down from composites that are actually deployed. Mere presence in a contribution should have no significance in this process. step 2: - extend that logic to other implementation types as well Agrred step 3: - not even read the entire composite until it's needed, just register its name in the ArtifactResolver and stop there (we just need the top level element to know its name), then actually read and process its contents later in the resolution phase It may not ultimately gain us much in performance, but it will make testing a damned sight easier. Testing can probe small pieces of a larger configuration - the last thing you want is some error in one part of a contribution screwing up tests running against some other part. I have started to experiment with step 1. I'm not sure yet about step 3 as I'll have to run concrete tests to evaluate what we actual gain by doing it. That covers the lazy loading part. Another aspect I'm starting to look into is incremental changes to an SCA domain, as we add/remove contributions, add/remove composites to/from an SCA domain in memory model, we need to configure/unconfigure bindings, wire/unwire references, break/fix pieces of the assembly model, incrementally. I'll post more ideas later on the subject, in a different thread. This calls for another thread of discussion. This is required. Part of the thinking here is that there may be different kinds of repository for contribution material - some "passive" like a file system, some "active" like a formal repository. Operations of adding/updating/removing elements in the repository should generate events that signal changes to the runtime, which the runtime must then act on. Another part of the thinking here is that in a distributed runtime, different parts of the Domain configuration will be targeted at different runtime nodes. There is a question about how it is decided that a given part of the domain ends up on a given node. Makes sense? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An observation about the current Contribution handling code
Simon, That's exactly what happens. If fact, it is far, far worse than that - it searches for ALL resources, not just composites. In the case of Spring, I have sets of application-context.xml files in there - and it creates pointers to all of them. Whether resolution occurs for all the resources simply depends on whether there are resolvers for each type of resource. In a distributed environment, this is going to be nightmarish. It has to be changed, in my opinion. Yours, Mike. Simon Laws wrote: I just tried this with the JMS test, i.e. added a second composite, and it does feel a little odd. In the case where there is no sca-contribution.xmlthe logc seems to look for the directory that holds the composite file you specify and load all the composites there rather that just the one you ask for. Is that right? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An observation about the current Contribution handling code
Simon, My test case uses: domain = SCADomain.newInstance(getCompositeName()); ...where the composite name returned is related to the name of the testcase that I'm running. I had assumed, perhaps wrongly, that this composite was the deployable entity in this case - since I don't have an explicit sca-contribution.xml. Yours, Mike. Simon Laws wrote: Mike By "I am pointing explicitly at a particular composite that I want to use with the test case" are you saying this behaviour is evident if your composite of interest is marked as deployable (in sca-contribution.xml ) when the others that are loaded are not? Regards Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
An observation about the current Contribution handling code
Folks, I made an observation while debugging my composite loading code in the Spring implementation that gave me pause for thought - and I'd like to see if the code that handles contributions is behaving the way people expect. I found that in my test case, I am pointing explicitly at a particular composite that I want to use with the test case. However, the contribution root is much higher up in the file system than the composite file (org.apache.tuscany. etc). The contribution root is taken from the top of the directory tree and the contribution handling code loads up everything it finds in the (sub)tree. It then resolves all of the artifacts it finds. This is done irrespective of whether the artifacts are going to be used. In particular, it resolves ALL composites found in the subtree - even if they are not in practice going to get used. Is this the desired behaviour? Certainly, it implies a lot more work than necessary (it's equivalent to eager loading of everything). In a test situation it can be very frustrating, since if anything in the contribution is in error in some way, the error gets hit even if the test you're running has nothing to do with it Comments, anyone? Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Raymond, Comments inline... Raymond Feng wrote: Hi, Let's look at a use case: Assuming we have a deployable composite as follows. should be available over the Web Service binding. Let's assume that the deployed URI is http://localhost:8080/MyComponent/MyService. Now it becomes interesting: Is "MyService" available for SCADomain.getService(MyService.class, "MyComponent/MyService")? If so, which binding should be used? Yes, the intention is that it is available. The binding that should be used is (one of) the bindings expressed by the service - in this case it's the web service binding. The binding should be compatible with the binding on the reference that wants to use it If the answer is yes, I think by the SCA spec, only Web Service binding is available to access MyService. Then the service proxy returned from SCADomain.getService(...) will be a self reference with a Web Service binding and the binding URI should be the SAME as the calculated service binding URI, i.e., http://localhost:8080/MyComponent/MyService. (I think the binding URI for the self reference is not correctly filled today and that's why the $self$ comes into the binding providers' faces). This is correct according to the SCA spec. The other option is that if the service doesn't have a SCA binding, SCADomain.getService(...) will throw ServiceUnavailableException. Nope, this should not happen unless the reference demands some different binding (eg JMS). Even then the exception looks wrong "IncompatibleServiceException" would be nearer the mark. Incompatibility could occur for a variety of reasons, incluing interface mismatch or Intent/Policy incompatibility. Thanks, Raymond - Original Message - From: "Matthew Sykes" <[EMAIL PROTECTED]> To: Sent: Wednesday, June 06, 2007 12:31 PM Subject: Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - 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]
