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 implementation.spring.../ 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 sca:service.../ elements in the application context file, those and only those are exposed as services (one for one) b) If there are NO explicit sca:service.../ 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: [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: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Jean-Sebastien, Jean-Sebastien Delfino wrote: snip 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: 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: 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 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 #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 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: [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: html body Hello! I can write XML without namespaces, isn't that nice? /body /html 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: 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 binding.axis2 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: 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 binding.ws, 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 binding.ws 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 binding.ws.../ 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: 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 mike.edwards.inglenook at ... 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: [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]
[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: 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]
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: Resolving WSDL/XSD import/include for SCA contributions
Hi, A few thoughts snip 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: Why SCA10 specify interface.java
Hi Shaoguang,
shaoguang geng wrote:
In SCA java component implementation 1.0, most of the spec was telling the story about interface.java
interface=[interface name]. But in fact implementation.java class=[class
name]/ has done every thing.
Dose osoa mean: using interface.java 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:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=CompositeA
component name=ServiceAComponent
implementation.java class=com.foo.ServiceImpl /
service name=ServiceName
interface.java interface=com.foo.ServiceA/
/service
/component
...
/composite
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 service.../ 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: [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 xsd:import or xsd:include is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, xsd:import namespace=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: 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: 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]
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: 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: binding.wsuri=jms:/dynamicTopics/something.TestTopic?transport.jms.ConnectionFactoryJNDIName=TopicConnectionFactoryjava.naming.factory.initial= org.apache.activemq.jndi.ActiveMQInitialContextFactoryjava.naming.provider.url=tcp://localhost:61616java.naming.security.principal=systemjava.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: 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 binding.ws transport.??? some transport config /transport.??? binding.ws 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: binding.ws requires=transport.jms/ or binding.ws requires=transport.http/ 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?
Simon Laws wrote: snip 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: 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]
[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: !DOCTYPE hibernate-configuration PUBLIC -//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: 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: 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: 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=revrev=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=diffrev=557494r1=557493r2=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. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent 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=diffrev=557494r1=557493r2=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. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent 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=diffrev=557494r1=557493r2=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. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample;
[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) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- 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: 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]
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]
[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: complexType name=SCAPropertyBase mixed=true !-- mixed=true to handle simple type -- sequence any namespace=##any processContents=lax minOccurs=0 maxOccurs=1 / !-- NOT an extension point; This xsd:any exists to accept the element-based or complex type property i.e. no element-based extension point under sca:property -- /sequence /complexType !-- complex type for sca:property declaration -- complexType name=Property mixed=true complexContent extension base=sca:SCAPropertyBase !-- extension defines the place to hold default value -- attribute name=name type=NCName use=required/ attribute name=type type=QName use=optional/ attribute name=element type=QName use=optional/ attribute name=many type=boolean default=false use=optional/ attribute name=mustSupply type=boolean default=false use=optional/ anyAttribute namespace=##any processContents=lax/ !-- an extension point ; attribute-based only -- /extension /complexContent /complexType ...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) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- 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: [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: complexType name=SCAPropertyBase mixed=true !-- mixed=true to handle simple type -- sequence any namespace=##any processContents=lax minOccurs=0 maxOccurs=1 / !-- NOT an extension point; This xsd:any exists to accept the element-based or complex type property i.e. no element-based extension point under sca:property -- /sequence /complexType !-- complex type for sca:property declaration -- complexType name=Property mixed=true complexContent extension base=sca:SCAPropertyBase !-- extension defines the place to hold default value -- attribute name=name type=NCName use=required/ attribute name=type type=QName use=optional/ attribute name=element type=QName use=optional/ attribute name=many type=boolean default=false use=optional/ attribute name=mustSupply type=boolean default=false use=optional/ anyAttribute namespace=##any processContents=lax/ !-- an extension point ; attribute-based only -- /extension /complexContent /complexType ...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) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online
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: 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: [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=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/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: 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: tuscany-dev@ws.apache.org 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: 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:
wsdl:definitions targetNamespace=http://pkg.my/v1;
xmlns:tns=http://pkg.my/v1; ...
...
!-- Defined in 'somens' --
xs:complexType name=MyType
...
!-- wrapper elem for operation 'm1' --
xs:element name=m1
xs:complexType
xs:sequence
xs:element name=param type=somens:MyType/
/xs:sequence
/xs:complexType
/xs:element
wsdl:portType name=MyIntf
wsdl:operation name=m1
...
I'm planning to use this MyIntf portType on an interface.wsdl 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:
interface.wsdl interface=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
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 implementation.osgi .../ 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]
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: 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]
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: 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 implementation.bpel.../ 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: 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: snip 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 snip 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]
test - please ignore
test - 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]
[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: !DOCTYPE hibernate-configuration PUBLIC -//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: 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: ?xml version=1.0 encoding=UTF-8? sca:composite name=NCName targetNamespace=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 sca:component name=test1 sca:service name=service1 /sca:service /sca:component /sca:composite 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: !DOCTYPE hibernate-configuration PUBLIC -//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: 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: implementation.java class=calculator.CalculatorImpl 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 implementation. 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]
[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]
[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: !DOCTYPE hibernate-configuration PUBLIC -//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: 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]
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=truepid=12310210reporterSelect=specificuserreporter=fuhweisorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC - 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. snip - 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
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. snip - 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, 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: 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: 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: snip 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. snip 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. snip 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. snip 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]
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]
[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]
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
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: 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: 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
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: 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 include or an implementation.composite) 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
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: Automated nightly builds
+1 from me Yours, Mike. ant elder wrote: On 6/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: Wouldn't that fail if you start from a clean repo ? It expects the other modules to be built or available as deployed snapshots no ? On 6/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Luciano Resende wrote: I'm looking for a distribution that I could use directly, as the individual JARs are not so useful. Is there a way to get the distribution built as part of the automated build? For DAS, I have a distribution profile that generate javadoc, distributions, etc Maybe we could do same for SCA (and SDO) , and I could use this profile on the automated builds. Thougths ? or maybe even simpler than a profile, is it possible to just add the distribution Maven module to the confluence build config? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I was thinking about building adding the distribution build after the sca build in the same confluence build config, but it doesn't look like it's possible, so I guess a build profile, as you suggested is the best solution. Another thought, how about adding a link to the nightly builds to the Tuscany SCA Java download page? What do people think? Yes thant would be good. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Steps to update the Web site, was: Website - Consistent navigation menus
Folks, I'd just like to say that if you need Confluence help, that I have some expertise in this area since I manage the www.osoa.org site, which is also based on Confluence. Yours, Mike. ant elder wrote: On 6/7/07, Luciano Resende [EMAIL PROTECTED] wrote: Do you have Confluence Admin rights ? We are trying to get couple of people with Admin rights in order to be able to resolve this infra issues. Otherwise we are dependent on the existent confluence admins, and Herman is one of the guys that are helping us. If we're going to need to be doing a manual export as a matter of course when certain pages are updated then could it be all committers that get admin rights? ...ant - 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. composite ... component name=MyComponent service name=MyService binding.ws .../ /service /component /composite When this composite is deployed to the SCA domain, then MyService 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: tuscany-dev@ws.apache.org 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]
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: 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]
Re: Website - Consistent navigation menus
Simon, I think that the idea is to split the material between official Website pages and general Wiki pages. The official website pages would be restricted to editing by committers. The rest of the Wiki can be open to editing by all. The simplest way for a non-committer to create something that is intended for the main website is to create the page in the Wiki area and then submit an email to the list with a URL to the page. Any committer can simply copy the page into the Confluence space for the offical website... At least, that's my interpretation ;-) Mike. Simon Nash wrote: With this new approach, how can a non-committer make a change? Will there be a mirror of the web site in the separate space with committer+CLA access where I can do this? Or will I need to create diff patches and attach them to a JIRA? Simon ant elder wrote: +1, it would be unfortunate to have the home paged covered in unsavory links by some spammer just as 0.90 has been announced. ...ant On 6/6/07, Simon Laws [EMAIL PROTECTED] wrote: Ok Hernan, thanks for your advice on this, I guess we can go with just having committers access on the space used to generate the website and them move everything else to a separate space with committers and cla access. Who do we ask for a new space? [EMAIL PROTECTED] Regards Simon - 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: Reactivating the implementation.spring extension, ready to go with the latest commits to sandbox
Jean-Sebastien, OK, with the latest commit to the sandbox, there is a working version of the Spring implementation. It has the fixes you need, plus a set of other changes which have got the basic version working. I'll hold off on further updates until it's in trunk. The next step is to get References working from the Spring implementation to some external SCA components. Yours, Mike. Jean-Sebastien Delfino wrote: I reviewed the update of the Spring extension that Mike has put in the sandbox and it looks like a good step to get the Spring extension going again. I just had to adjust a few lines to use the 0.90 release SPIs to get it building with the level of code in trunk. I'll commit these fixes later today. Then I'd like to replace the old modules/spring-implementation in trunk (which is broken) by this update. If there's no objection I'll do that sometime tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using service name to call a service
Muhwas, I dont understand what you are saying here. Surely, the actual service has a specific interface - it isn't simply anything, so you can only cast to the actual business interface it actually implements. Or did you envisage your client code introspecting the returned service proxy and dealing with whatever it found? The latter case is possible but it is not a pattern I would encourage people to use - the code is likely to get very complex. I can see a possible use for it in writing test clients, where the parameters are actually presented in a GUI for a user to fill dynamically. However, this is not typical of real business code. Yours, Mike. muhwas wrote: by the way i used this CompositeContext compositeContext = CurrentCompositeContext.getContext(); // get service reference using service component name in client side default.scdl return compositeContext.locateService(java.lang.Object.class,serviceName); and then i casted it to what ever interface type i want to. so i think passing in interface doesn't nessasary. --- scabooz [EMAIL PROTECTED] wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Logo..
Haleh, I've added a bell tower on the Logo page Mike. haleh mahbod wrote: It would be good to have an icon to associate the Tuscany project with. If you look at Cayanne[1], they have the pepper. For Geronimo [2] it is is the letter G, for lucene[3] it is the name itself. I am gathering that noone likes logo2 (which includes an icon) ? Is it the color? Or the whole thing? Any other ideas? [1]:http://cayenne.apache.org/ [2]:http://geronimo.apache.org/ [3]:http://lucene.apache.org/ Haleh On 5/18/07, Luciano Resende [EMAIL PROTECTED] wrote: On 5/18/07, Raymond Feng [EMAIL PROTECTED] wrote: Can we just remove the left side from Logo 1? My first false impression was they are for two logos. +1 Thanks, Raymond - Original Message - From: Kevin Williams [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 18, 2007 10:55 AM Subject: Re: Tuscany Logo.. Logo 1 is still best. We just need a better image for the left side. On 5/18/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, like the others I like Logo 1 but find the picture on the left to be out of place - does not gel well with the rest of the image. Also if 'Apache' in 'Apache Tuscany' could be right aligned it would look a little better I thought. - Venkat On 5/18/07, haleh mahbod [EMAIL PROTECTED] wrote: posted a new logo. You'll find Logo1, Logo2, Logo 3 http://cwiki.apache.org/confluence/display/TUSCANY/TuscanyLogos On 5/17/07, Mike Edwards [EMAIL PROTECTED] wrote: Haleh, As others have said, the right hand side is superb - keep it. The cypress image is a good idea, but the particular one that you have doesn't look effective when it is Icon sized - it's too detailed and fussy. Better to have a simpler image with fewer, bolder trees. I'll have a hunt to see if I can find one. Whoever put that image up of Van Gogh's painting will get us into copyright trouble - I suggest removing it ASAP !! The other image characteristic of Tuscany are bell towers, like the ones in Siena and Florence Yours, Mike. haleh mahbod wrote: Here is another try. I moved the logos to this link: http://cwiki.apache.org/confluence/display/TUSCANY/TuscanyLogos On 5/17/07, Simon Laws [EMAIL PROTECTED] wrote: snip If yes, I'll go ahead and add it to the website ( I'll need help for doing this correctly please ). If you want to put a logo up on the site in place of the confluence logo (the man type thing with a C wrapped round him) then there is an option under space admin to set the space logo. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende 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]
Problem I had with SCA Itests - Need to update the POM for the Itests?
Folks, I ran into a problem building and running the Itests for SCA. I was unable to get the jaxws-maven-plugin resolved and the whole thing failed - this was despite there being a copy of the plugin in my local repository - it just turned out to be unacceptably old for some reason best known to maven. The POM for the Itests has an entry for the java.net Maven 1.x repository, which I think is the expected place for resolution of the jaxws plugin: pluginRepository snapshots enabledtrue/enabled /snapshots idjava.net/id namejava.net Maven 1.x Repository/name urlhttps://maven-repository.dev.java.net/repository/url layoutlegacy/layout /pluginRepository However, the jaxws-maven-plugin project has moved on. The plugin isn't in that repository any longer. Instead it is in the Maven 2 repository on java.net: pluginRepository snapshots enabledtrue/enabled /snapshots idmaven2-repository.dev.java.net/id namejava.net Maven 2 Repository/name urlhttp://download.java.net/maven/2/url layoutdefault/layout /pluginRepository Adding this second plugin repository to the POM and cleaning out my local repository enabled things to work correctly. Unless folk object, I propose to commit an update to the POM for the itests with this extra plugin repository declaration - it is definitely the right location for the most up to date version of this plugin. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Logo..
Haleh, As others have said, the right hand side is superb - keep it. The cypress image is a good idea, but the particular one that you have doesn't look effective when it is Icon sized - it's too detailed and fussy. Better to have a simpler image with fewer, bolder trees. I'll have a hunt to see if I can find one. Whoever put that image up of Van Gogh's painting will get us into copyright trouble - I suggest removing it ASAP !! The other image characteristic of Tuscany are bell towers, like the ones in Siena and Florence Yours, Mike. haleh mahbod wrote: Here is another try. I moved the logos to this link: http://cwiki.apache.org/confluence/display/TUSCANY/TuscanyLogos On 5/17/07, Simon Laws [EMAIL PROTECTED] wrote: snip If yes, I'll go ahead and add it to the website ( I'll need help for doing this correctly please ). If you want to put a logo up on the site in place of the confluence logo (the man type thing with a C wrapped round him) then there is an option under space admin to set the space logo. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get to the interferface defined on a reference from the binding?
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: ComponentReference.getReference() should give you the reference on the component type. Thanks, Raymond ComponentReference.getReference() will give you the reference from the ComponentType. I think that Ant is looking for the CompositeReference promoting the ComponentReference, and the interface that it declares. I think this issue is only on the reference side, on the service side we create a ComponentService with the characteristics of each CompositeService. We may have to follow the same pattern as for ComponentReferences and CompositeReferences. I'll dig into this a little more and should come back with a proposal to address this later today. - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 11, 2007 8:29 AM Subject: Re: How to get to the interferface defined on a reference from the binding? I didn't think so as the RuntimeComponentReference instance passed in to the createReferenceBindingProvider method has the InterfaceContract of the component's reference not the interface inside the reference. Maybe thats just a bug? You can see this if you change sample-helloworld-ws-reference helloworldwsclient.composite to use the interface.wsdl from the previous email and then with a break point at Axis2BindingProviderFactory.createReferenceBindingProvider (or anywhere else in the Axis2 binding code), I couldn't find anything pointing to the WSDL interface. ...ant On 5/11/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Do the following methods give you enough information? ReferenceBindingProviderM createReferenceBindingProvider(RuntimeComponent component, RuntimeComponentReference reference, M binding); ServiceBindingProviderM createServiceBindingProvider(RuntimeComponent component, RuntimeComponentService service, M binding); The binding class should be able to take the interface contracts from the service/reference when the binding providers are created. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, May 10, 2007 7:28 AM Subject: How to get to the interferface defined on a reference from the binding? I'm trying to get binding.ws to work without specifying all the WSDL info, for example like this: reference name=HelloWorldService promote=HelloWorldServiceComponent/helloWorldService interface.wsdl interface= http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=HelloWorldServiceComponent/HelloWorldWebService / /reference but i can't find any way to get to the whats defined in the interface element of the reference. None of the runtime objects seem to have any link back to the references InterfaceContract. Should this be possible? ...ant After investigating this issue a bit more. Here's some thoughts and a proposal: - We currently push the bindings specified on composite references down to the component reference that they promote. We should push the interface contract defined on the composite reference as well, as it defines the actual contract that needs to be used on the wire to a target component. - Code that injects references into a component implementation should be changed to use the interface of the reference declare in the component type instead of the component reference, as the object injected into the implementation really needs to comply with that interface, and not any other matching interface declared on the component reference or any of the composite references that promote it. With these two changes, in your particular scenario: - componentReference.getInterfaceContract() will return the WSDL interface. This is what you want to use to talk on the wire. - componentReference.getReference().getInterfaceContract() returns the interface contract expected by the component implementation. Component reference injection needs to use this one (we'll have to adjust the Java and Script implementations to do that), this will ensure that the component implementation gets exactly what it said it required. Makes sense? +1 - both for services and for references, there is a separation between the interface that the component implementation uses (which is the one that turns up the component type) and the interface which applies to the wire. For a service, the wire interface contract can be narrower than the component service (ie only a subset of the supplied service is used), while for a reference, the wire interface can be wider than the component reference (ie more capability is available than is used). It makes a practical difference for references in that multiple component references can be promoted by a single composite reference. For services, this isn't the case. Yours, Mike.
Re: Scheme validation
ant elder wrote: On 5/4/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Nicholas Williams wrote: My understanding is that Tuscany does not currently validate SCDL against the schemas. Assuming that this is correct, when do you think such functionality will be introduced? Thanks Nick Williams Good idea. We should validate .composite/.componentType/.constrainingType files when we initially load them and report any XML schema validation problems then, and this will greatly improve our error reporting story. These files are loaded by Composite/ComponentType/ConstrainingTypeDocumentProcessor (in module tuscany-assembly-xml). It should be easy to add the validation there. To do this we'll need the schemas in our distribution. The SCA 1.0 schemas and license.txt are there: http://www.osoa.org/xmlns/sca/1.0/. However, before we include them I think we need to review their license. Since it's not an Apache License, we need to get an approval covering this 3rd party license. We'll probably have to adjust our NOTICE file to list that 3rd party license as well. Is this something we'd like to do as part of the upcoming release? This is just a few lines of code, the benefit is much better error reporting, and it's probably the right time to look at this license issue now as we are going to have to review all our other NOTICE and license files anyway. What do people think? It does sound like it would be good to do validation. We need to clarify the OSOA license anyway as the Tuscany SDO distribution is already distributing things covered by it. The OSOA license was asked about on the legal-discus list a couple of months ago [1] and no answers were given other than being asked why OSOA couldn't just use a standard license (which seems like a very good question to me). Two issues are, the one already mentioned on legal-discuss about being a compliant implementation, and another is it says we can redistribute the INTERFACE DEFINITION FILES but the SDO API also contains some implementation classes so its not clear if we have a license to use those. Given there wasn't any clear answer last time it was asked about on legal-discuss its likely we can't get this clarified in time for the upcoming release. But, I'm pretty sure its OSOAs intention that we should have rights to use the files, and as we've already done a couple of SDO releases which have cleared all the reviews how about we just go ahead and use them for now as we're still incubating but just make sure its sorted out by the time we graduate? ...ant [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200702.mbox/[EMAIL PROTECTED] Folks, What makes me smile about this legal point is that nowhere does OSOA ever define what is meant by a compliant implementation. The lawyers drafted the terms of the license - the reason for not using some standard license like Apache is that it was intended that the files should not be modified - they are meant to represent the content of the specification. However, the current OSOA specs don't have conformance statements in any recognised form. Neither is there a compliance test suite to validate compliance to such conformance statements. So I would argue that using the phrase compliant implementation is meaningless for the OSOA specs. How could anyone argue whether a particular implementation is compliant or not? However, I'm no lawyer. No doubt law-folk will take a different view. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Demo
Jean-Sebastien, +1 for sca/demos/bigbank I'd like to show it at IMPACT 2007 in Orlando week after next - I may ask for some help next week as I prepare ;-) Thanks for preparing it - it helped to give the JavaOne BOF some much needed reality ! Yours, Mike. Raymond Feng wrote: Hi, It's a very nice demo. I prefer to have it under sca/demos/bigbank. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Saturday, May 12, 2007 10:29 AM Subject: JavaOne Demo Hi all, I would like to commit the three modules that I have put together for demos of Tuscany/SCA at JavaOne. The demo is a variation of the BigBank scenario that we've been using in Tuscany and some of the SCA documents to illustrate the SCA programming model. This is a sample banking application that takes your customer id and first gets information on your checking, savings, and stock account, gets stock prices from a stockquote service, converts it to a configured currency using a bunch of calculator components and returns the total balance of all your accounts. The application is implemented as a set of SCA composites and components wired together and running on different JVMs: - A StockQuote Java component (returning random stock prices) providing a StockQuote service with a Web Service binding. - A Calculator composite containing a fancy Calculator assembled with 4 components written in different scripting languages (Ruby, Groovy, Python and Javascript) implementing the 4 basic operations of a calculator, providin a Calculator service with an RMI binding. - An AccountData composite containing an AccountData Java component returning account information, used as a nested composite with an SCA default binding in the BigBank composite. - A BigBank composite, containing an Account Java component wired to the above components, implementing the logic to retrieve account data, the stock quote info, perform a currency conversion and sum the balances of your three accounts. The Account service is provided with both a Web Service binding and a JSON-RPC binding. - A simple J2SE client program for the Account service as well as a Web 2.0 client user interface using DOJO and JSON-RPC to call the Account JSON_RPC service directly from your Web browser. The demo can run from a command line with the J2SE client, or you can deploy it to Tomcat and then run it from your Web browser. I posted a diagram showing the SCA assembly for the demo on our Wiki there: http://cwiki.apache.org/confluence/display/TUSCANY/JavaOne+Demo This demo shows many aspects of SCA: - Recursive SCA assembly using the SCA specification 1.0 syntax. - Assembly of Java components and components written in 4 other languages. - SCA Java annotations. - Web Service, RMI and JSON-RPC bindings (plus the SCA default binding used inside the composites). - SCA components running on different servers in an SCA domain. - An SCA client programming model to invoke services in the SCA domain. Where do people think it should go? samples? demo? demo-javaone? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA] WSDL2Java seems not generating SDO code
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: Yang ZHONG wrote: WSDL has schemas and portTypes. WSDL2Java uses SDO CodeGen to compute classes names for schemas and generates classes for portTypes. SDO code seem not actually generated. Is that desired? If not, I can look into how to fix. If yes, are users supposed to use SDO CodeGen themselves? If so, what if users specify options causing different code from what WSDL2Java expects? How do we enable users to reflect the customization to WSDL2Java? Yang, If I remember correctly, the current WSDL2Java tool does not automatically run XSD2Java for all the inline XSDs or all the XSDs referenced from the WSDL. Application developers are responsible to run the WSDL2Java tool or XSD2Java tool on each individual WSDL or XSD file. On one hand, it would be nice to support a top-down generation from a WSDL including the closure of all the referenced XSDs. On the other hand if multiple WSDLs reference common XSDs you probably don't want to regenerate code for these XSDs multiple times. Also if an application developer starts to work on an XSD he'll probably want to generate SDOs from it even before writing a WSDL, then later when he generates a Java interface from that WSDL, the interface will have to point to these SDOs... As you noted things will break if incompatible codegen options are used in XSD2Java and WSDL2Java. These issues are actually not specific to WSDL, you can run into similar issues with a graph of XSDs... We should start a discussion to find the best strategy for this codegen: a) Handle generation on an SCA contribution basis (basically you don't gen from individual files but you handle in a single pass ALL relevant files in the contribution, with consistent codegen options and avoiding duplicate gen). b) Or continue with the current approach where the app developer specifies which files to gen from (including support for *.wsdl or *.xsd). c) Or add support for top-down generation of a closure from a WSDL or an XSD. d) Or any other scheme... My preference would be for keeping option (b) and build option (a) on top of it, but I think it'll help to look at how existing similar tools are handling this: How does the current XSD2Java tool handle this? What does it do when you give it an a.xsd containing an import/ of another b.xsd? Does it generate code only for a.xsd? or for both a.xsd and b.xsd? What about the JAXWS tools? Thoughts? One more thought, for option (a) we should be able to reuse the SCA Contribution service to find all the WSDLs and XSDs used in an SCA contribution (as well as the namespaces imported from other SCA contributions) to automate the calls to the WSDL2Java and XSD2Java codegen and generate everything the SCA contribution needs. It seems to me that different usecases apply. It should be possible just to point the tool at some remote WSDL / XSD and generate the required Java files locally, without needing to download the WSDL and XSDs. One of the points of convenience here is that the Java programmer wants as little to do with the WSDL and XSDs as possible - what they are really after are the Java interface files and the SDOs - those are what they will work with. Ideally they DONT want the WSDL and XSDs in their contributions. So an option (at least) should allow the user to request that the tool follows all links and generates all the target entities. Another option should allow for bulk creation - ie a run against not just a single file but a whole series of them - and that the tool should only gen each target once for the whole run (ie spot when the same WSDL or XSD is processed more than once). It seems reasonable to allow just a single file to be processed, but I doubt whether that is what I would want as a default. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Specs Related] Queries on References
Venkat, Responses inline Yours, Mike. Venkata Krishnan wrote: Hi, I am trying to bring the SPI model and the Loaders in sync with the current level of the specs as available on OSOA site. I am currently looking at 'references' - as and how they are defined in ComponentType, ComponentDefinition and Composite and have the following questions: - With respect to references defined in ComponentDefitions and the 'target' attribute therein - the specs says that whatever is mentioned in the target overrides that which is mentioned in the implementation. Now, my understanding is that a target is used to wire a reference to another Component's service. Given this, I thought defining a target makes sense only within a composite. So what does it mean by an implementation specifying a target for a reference? Part of the recent work on the Assembly spec allows for fully configured implementations. In effect this means that an implementation can contain full SCA metadata and that the implementation can be deployed without the need for any further configuration metadata. An example might be a Java class bristling with annotations, which could include annotations for references that would include target information. The targets would be meaningful in terms of an SCA domain into which the implementations are deployed eg fooComponent/barService as a target spec, where fooComponent is known to be another component deployed to the Domain. Under these circumstances, if there is a need to reuse such a fully configured implementation, then the composite (re)using the implementation must have the means to override the metadata in the implementation. - next, the 'target' attribute for a reference in a component definition is 'optional'. Assuming there are no targets defined in the implementation and no targets are defined in the component definition that uses this implementation (as this is only optional), then what happens to these references. Is this something that should not be permitted unless autowire=true for the reference defn. Remember that a wire can EITHER be specified using the target attribute of a reference OR using a standalone wire element. Forgetting about autowire and promotion and wiredByImpl, it IS a requirement that a (1..1 or 1..n) reference is not left dangling. It is an error if there is no wire under these circumstances. Clearly for (0..1 and 0..n) multiplicity, a reference can validly be left unwired. The use of standalone wire elements is of particular use at the Domain level, where wiring can be deployed separately from the components, allowing separation of responsibilities. Could somebody familiar with the specs kindly help me with understand? Thanks. - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence Wiki questions
Luciano, Removing a page is dreadfully simple - be cautious about its use. Go into Edit mode on the page you want to delete. On the top right of the editing pane, you will find a trash can icon with a link labelled Remove Page. Click on either the trash can or the text and that will delete the page. Reparenting a page is also fairly straightforward. Again in Edit mode, you will see the name of the page at the top. Immediately below the name is a string saying something like: Location: Apache Tuscany Home Foo EDIT The string following Location: is the path from the root of the space to the page you are editing, apart from the EDIT which is a button which you press to change the parentage of the page. If you press that link, you are presented with Space and Parent Page fields. To change the parent page, select the search icon to the right of the field - selecting Search with a * wildcard will get you a list of all pages in the Apache Tuscany space - you can select which one you want as parent. Enjoy! If you're wondering how I know this - it's because www.osoa.org is based on the Confluence wiki software as well I know, I need to get a life... Yours, Mike. Luciano Resende wrote: I'd like move more contents from DAS website and old wiki to our current confluence wiki. I'll probably need to delete some pages, or a way to refactor/reparent pages in order to proper organize the contents. Is there a way to reparent pages ? Otherwise, wow can one get access to remove pages in our new confluence Wiki ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany java SCA M2 issues, was: Lingering questions
Ant, Yes, I hit this problem with Woden. The fix you outline below does not work. It looks as if maven is not using that version of the POM for the samples from my local disk. So editing that version has zero effect :-(. This maven build process is nothing less than a nightmare. When things go wrong, they screw up in ways that mere mortals cannot fathom. Yours, very frustrated, Mike. ant elder wrote: Another problem is that Woden has been moved so now i think is not in the maven repositories searched by the samples, and this could cause the failure of the axis2 extension. So if its not in your local repo you need to add the following to the repositories in the pom.xml in the top level directory where the samples are unzipped. repository idapache.ws/id nameApache WebServices Repository/name urlhttp://ws.zones.apache.org/repository//url layoutlegacy/layout /repository Even after this and all the other changes suggested bigbank fails for me when i run it with: java.lang.NoSuchMethodError: bigbank.webclient.tags.sca.ServiceTag.setClazz (Ljava/lang/String;)V Has anyone else actually tried and got working the M2 samples recently from an empty local maven repo? ...ant On 2/27/07, Mike Edwards [EMAIL PROTECTED] wrote: Raymond, Thanks for your reply. I had seen your previous note and I tried applying the lines: init-param param-nametuscany.online/param-name param-valuefalse/param-value /init-param into the web.xml file within the deployed Tomcat webapp. Unfortunately, it makes no difference. The axis2 jar is still not found with exactly the same error as before. Can you explain how it is that this jar is actually packaged with the webapp and is there in the deployed directory structure, but is not found? What was the purpose of it being packaged that way if the runtime code does not look for it there? Clearly, maven running on my system was able to find that jar at build time - but it can't be found at runtime?!? Are there any further system variables of any kind that I need to apply anywhere? Yours, Mike. Raymond Feng wrote: Hi, Mike. It seems that you're seeing similar issues with M2. Please see my comments below and they might help. Thanks, Raymond - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Monday, February 26, 2007 3:17 PM Subject: Re: Lingering questions Hi, David. Thank you for trying Tuscany and posting questions. Please see my comments below. Raymond - Original Message - From: David Woolley [EMAIL PROTECTED] To: tuscany-user@ws.apache.org Sent: Monday, February 26, 2007 10:08 AM Subject: Lingering questions I've been using Apache Tuscany for a few weeks now. Here are some lingering questions based on my experiences with m2. Maven dependencies. I have used the samples and created my own prototypes. The maven dependencies within Tuscany is still somewhat mystifying for me and I still see errors about being unable to connect to external repositories even when I've packaged my own war file. And firewalls can also cause issues for me. It's a bit unfortunate. :-( I'm not sure if the following post will help: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13230.html My last error for example is Unable to resolve artifact: org.apache.tuscany.sca.services.bindings:axis2:1.0-incubator-M2:jar [org.apache.tuscany.sca.services.bindings:axis2:1.0-incubator-M2:jar]. Which oddly enough worked on the weekend but now doesn't.I assume a firewall issue or repository being down.or something..because the jar file is in the extensions directory within the tuscany.folder within WEB-INF There are various mentions of using offline for building the war file but quite simply I'd just like to do something with the war file I have packaged myself to turn this behaviour off. Is there such a thing? Is it this System Property (offline=true) or some other variant? Can it be passed to the Tuscany servlet or can I simply move some libraries around? System property offline is used for standalone runtime. For web applications, you can set an init-parameter named tuscany.online to false by adding the following to the web.xml: init-param param-nametuscany.online/param-name param-valuefalse/param-value /init-param Logging I'd like to see some examples of the use of logging within components (@Monitor etc). I've read the sample in the wiki of how to replace the default logger but as far I can see the samples don't use whatever the default is out of the box. Jim, can you give David a pointer? Passing Context Is there anyway to pass some context between components that have been wired together? I'll leave it to Jeremy. IIRC, we had similar discussions before. Plugging
Re: Tuscany java SCA M2 issues, was: Lingering questions
Ant, Thanks for all your help. I've got the build and deploy to work with everything packaged inline, following your advice. However, the samples still dont actually work - I get a 404 when I point my browser at http://localhost:8080/sample-bigbank-webclient or at http://localhost:8080/sample-bigbank-account Any ideas about that? This is one of the poorest user experiences I've had in a long time. Yours, Mike. ant elder wrote: Did you try another mvn install -N in the top level directory after you updated the top level pom.xml, otherwise the samples will still be using the old pom.xml in your local maven repo. I agree its not easy, which is why I've always argued a pre-built distro complete with everything in a single download zip makes for a much easier first time experience. ...ant On 3/2/07, Mike Edwards [EMAIL PROTECTED] wrote: Ant, Yes, I hit this problem with Woden. The fix you outline below does not work. It looks as if maven is not using that version of the POM for the samples from my local disk. So editing that version has zero effect :-(. This maven build process is nothing less than a nightmare. When things go wrong, they screw up in ways that mere mortals cannot fathom. Yours, very frustrated, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec schemata, was: Review of spec classes wanted
Folks, 1) I am arranging to publish all of the SCA spec schemas on the www.osoa.org site - we've completed a site upgrade that now allows us to publish random files outside the Wiki. So, expect to see the 1.0 SCA XSDs on http://www.osoa.org/xmlns/. by the end of today. Please note that these versions will be the ones input to the spec publication process and that at least one error has been identified that is likely to cause a change to the files before final publication. 2) The license applying to the files allows for repackaging as part of an implementation so I think you are OK to include them - and the Java API files. Yours, Mike. Jean-Sebastien Delfino wrote: [snip] Jeremy Boynes wrote: The sca-api module contains old versions of the schemas from 0.9 days. I think we should remove these from the jar as they are orthogonal from the Java APIs. We could package them separately, on our website, or just leave them to the spec to publish (as the URIs point back to their website). -- Jeremy I think that they should be published on the web site and also packaged in Tuscany distributions. Does anybody know if there will be any license issue if we want to package them in Tuscany? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spec schemata
Folks, I can confirm that the current 1.0 spec schemas are available on http://www.osoa.org/xmlns/sca/1.0/.xsd Yours, Mike. Jeremy Boynes wrote: The sca-api module contains old versions of the schemas from 0.9 days. I think we should remove these from the jar as they are orthogonal from the Java APIs. We could package them separately, on our website, or just leave them to the spec to publish (as the URIs point back to their website). -- Jeremy On 2/25/07, Jeremy Boynes [EMAIL PROTECTED] wrote: I've been through the sca-api-r1.0 classes and tried to bring them in line with the specification, including applicable errata :-) Apart from one issue with @Property I think they are now in alignment. It would be good if a couple of other people could review these so we can release them. Any volunteers? Thanks -- Jeremy - 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]
