Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 14, 2006, at 10:41 PM, Venkata Krishnan wrote: Hi Jim / Jeremy, I have been able to go forward quite a bit. Cool - Which is the scdl into which I must add the RMIHost component. I added it first to the system.scdl in SCA-API project. But that did not get picked up by the loader. When I debugged I figured out that it was the system.scdl in the SCA-Test project that was being loaded for system components. So added it there and it did get picked up. Is this right? There is something that I am missing here.. where should I be adding this component actually. I would suggest adding it to the SCDL in the extension - this would only be activated if the RMI binding extension was active. - I have added 'Module' scope for the RMIHostImpl and have the eager init decoration as well. - I have added the autowire annotations to the constructor of the RMIBindingBuilder. When I run, the RMIHostImpl is picked up and injected into the builder. But then I have having some strange exceptions in the DirectoryScanner and in the creation of the target invoker. I shall work to get over this and see if I can post a patch tonight. What exceptions (can't help if we don't know :-) )? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-611) RMI Binding
Hi Jim / Jeremy, I have been able to go forward quite a bit. - Which is the scdl into which I must add the RMIHost component. I added it first to the system.scdl in SCA-API project. But that did not get picked up by the loader. When I debugged I figured out that it was the system.scdl in the SCA-Test project that was being loaded for system components. So added it there and it did get picked up. Is this right? There is something that I am missing here.. where should I be adding this component actually. - I have added 'Module' scope for the RMIHostImpl and have the eager init decoration as well. - I have added the autowire annotations to the constructor of the RMIBindingBuilder. When I run, the RMIHostImpl is picked up and injected into the builder. But then I have having some strange exceptions in the DirectoryScanner and in the creation of the target invoker. I shall work to get over this and see if I can post a patch tonight. Thanks - Venkat On 8/14/06, Jim Marino <[EMAIL PROTECTED]> wrote: On Aug 13, 2006, at 11:00 PM, Jeremy Boynes wrote: > On Aug 13, 2006, at 10:42 PM, Venkata Krishnan wrote: >> - each registry is identified by a port on which it runs. I am >> not sure >> how hostname can be used for services. However, for references >> host names >> has a role to play. Right? > > For services it would determine the address that the port would > apply to. The default (0.0.0.0) would be all addresses on the > machine but for multi-homed machines it is quite often useful to be > able to specify a particular interface. > >> - RMI Host will be the interface thro which RMIBinding will register >> services into one of the registries (based on the port number >> specified) >> >> Can you please point me to some code that I can emulate to >> implement RMI >> Host in terms of how it should be implemented as a system >> component that can >> be autowired into the builder. Right now I am looking at >> LoaderRegistry to >> understand the programming model for this. Am I on track? > > That's as good as any. If you start with a POJO and just decorate it according its methods with @Init and/or @Destroy as needed you should have most of it. I'll keep an eye out and help when needed. Jim > -- > 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]
Re: Create distribution for bindings, or how to switch binding implementations
Jervis I agree with this. I view the extension dir as just one way extensions could be installed - there's nothing special about this mechanism, it is simply triggered by having a DirectoryScanExtender component loaded as part of the system composite. I think there is a problem with the spec in the way that it defines bindings based on a particular technology - for example, as if a runtime would only support one implementation for that technology. Fortunately the spec does allow for non-specified bindings so we could, for example, support and with no problem. I would suggest that we do. To address your point 1), some users prefer configuring servers just by copying files or directories to the right place. On some platforms that is the normal way to install applications. I think this works if the extension can be packaged as a single file, either some form of archive with nested dependencies like Ant was proposing, or a archive/file with external dependencies as I had been suggesting. The launcher environment we have been using is a fairly simple client which is focused on just running a single composite. It would be possible to define a more complex distribution that contained a whole bunch of server components and multiple application composites providing multiple services - something akin to Tomcat's webapp directory. This could use the same mechanism as e.g. the DirectoryScanExtender but I think it is important to keep a separation between artifacts used as server extensions and those used by application code. I think a simple approach here would be to allow the extension directory to contain simple SCDL files (xml files) that define composites and which get their code through dependencies. I think this would also give the config file approach you suggested. Is this something you would be interested in working on? -- Jeremy On Aug 14, 2006, at 7:55 PM, Liu, Jervis wrote: Hi, I can see from yesterday's IRC chat that we had a quick discussion on how to create distribution for bindings. I think the main problem we are facing is how to switch binding implementations. For example, we may want to switch the implementation of binding.ws between axis2 and celtix for helloworldws sample, in an easy and user friendly way. The approach Jeremy proposed should work: package the binding as an extension and somehow install it into the runtime(put it into the extension dir?) . So this is definitely one option. But I think we should also provide alternatives to better address following scenarios: 1, Tuscany users installed a generic Tuscany distribution, and they would like to be able to switch binding implementations without moving libraries around or changing any directories. I think we can improve usability if users only need to change a config file. 2. Some applications may want to use two binding implementations at the same time. It seems to me that we will need a configuration somewhere to specify the specific binding implementation. Can we have a proprietary entry in scdl file sth like or ? Any comments are welcome. To better track this thread, I have created jira 621. https:// issues.apache.org/jira/browse/TUSCANY-621. I also enclosed relevant IRC chat log for your info. Thanks, Jervis (05:27:47) cr22rc: jboynes : I'm ok about taking it out .. but what are we looking for doing for samples needing axis wsbservice binding (05:28:44) jboynes: I want to package the axis binding as an extension that can be installed in the runtime (05:29:46) jboynes: so to run the sample you add the axis extension to your installation (05:30:43) ant: or we may have a distribution that includes axis right? (05:31:03) jboynes: sure (05:32:32) jboynes: I want to make sure that the basic concept (core + a bunch of extensions) works (05:33:19) kgoodson left the room (quit: Read error: 110 (Connection timed out)). (05:33:23) ant: could we talk about the ServletHost stuff now? (05:33:33) jboynes: so we don't end up in a situation where an extension only works if it is packed into a distro in a special way (05:33:40) jboynes: I need a couple more (05:33:48) jboynes: I need to eat (05:35:32) ant: ok, well ping when you're ready (05:48:04) jboynes: ant: hi, better now I've had breakfast :) (05:48:30) ant: yum (05:48:31) jboynes: sorry for holding things up - I just reached the pass out or get cranky phase (05:48:48) dkulp left the room (quit: "using sirc version 2.211 +KSIRC/1.3.12"). (05:49:19) ant: ok so there's an interface ServletHost (05:50:02) jboynes: yep (05:50:10) ant: so the WS binding should use that to register a servlet for each ws endpoint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-620) Update DAS headers and copyright policies
[ http://issues.apache.org/jira/browse/TUSCANY-620?page=all ] Kevin Williams closed TUSCANY-620. -- Fix Version/s: Java-Mx (was: Java-M2) Resolution: Fixed Verified with revision: 431505 > Update DAS headers and copyright policies > - > > Key: TUSCANY-620 > URL: http://issues.apache.org/jira/browse/TUSCANY-620 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-Mx > > Attachments: lresende.patch.java.asj.headers.20060814.txt > > > Need to update DAS source files with updated header and copyright policies > from ASF, see thread initiated by jboynes : > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/thrd6.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Create distribution for bindings, or how to switch binding implementations
Hi, I can see from yesterday's IRC chat that we had a quick discussion on how to create distribution for bindings. I think the main problem we are facing is how to switch binding implementations. For example, we may want to switch the implementation of binding.ws between axis2 and celtix for helloworldws sample, in an easy and user friendly way. The approach Jeremy proposed should work: package the binding as an extension and somehow install it into the runtime(put it into the extension dir?) . So this is definitely one option. But I think we should also provide alternatives to better address following scenarios: 1, Tuscany users installed a generic Tuscany distribution, and they would like to be able to switch binding implementations without moving libraries around or changing any directories. I think we can improve usability if users only need to change a config file. 2. Some applications may want to use two binding implementations at the same time. It seems to me that we will need a configuration somewhere to specify the specific binding implementation. Can we have a proprietary entry in scdl file sth like or ? Any comments are welcome. To better track this thread, I have created jira 621. https://issues.apache.org/jira/browse/TUSCANY-621. I also enclosed relevant IRC chat log for your info. Thanks, Jervis (05:27:47) cr22rc: jboynes : I'm ok about taking it out .. but what are we looking for doing for samples needing axis wsbservice binding (05:28:44) jboynes: I want to package the axis binding as an extension that can be installed in the runtime (05:29:46) jboynes: so to run the sample you add the axis extension to your installation (05:30:43) ant: or we may have a distribution that includes axis right? (05:31:03) jboynes: sure (05:32:32) jboynes: I want to make sure that the basic concept (core + a bunch of extensions) works (05:33:19) kgoodson left the room (quit: Read error: 110 (Connection timed out)). (05:33:23) ant: could we talk about the ServletHost stuff now? (05:33:33) jboynes: so we don't end up in a situation where an extension only works if it is packed into a distro in a special way (05:33:40) jboynes: I need a couple more (05:33:48) jboynes: I need to eat (05:35:32) ant: ok, well ping when you're ready (05:48:04) jboynes: ant: hi, better now I've had breakfast :) (05:48:30) ant: yum (05:48:31) jboynes: sorry for holding things up - I just reached the pass out or get cranky phase (05:48:48) dkulp left the room (quit: "using sirc version 2.211+KSIRC/1.3.12"). (05:49:19) ant: ok so there's an interface ServletHost (05:50:02) jboynes: yep (05:50:10) ant: so the WS binding should use that to register a servlet for each ws endpoint
[jira] Created: (TUSCANY-621) Create distribution for bindings, or how to switch binding implementations
Create distribution for bindings, or how to switch binding implementations -- Key: TUSCANY-621 URL: http://issues.apache.org/jira/browse/TUSCANY-621 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding, Java SCA Celtix Binding Reporter: Jervis Liu I think the main problem we are facing is how to switch binding implementations. For example, we may want to switch the implementation of binding.ws between axis2 and celtix for helloworldws sample, in an easy and user friendly way. The approach Jeremy proposed should work: package the binding as an extenstion and somehow install it into the runtime(put it into the extension dir?) . So this is definitely one option. But I think we should also provide alternatives to better address following scenarios: 1, Tuscany users installed a generic Tuscany distribution, and they would like to be able to swtich binding implementations without moving libraries around or changing any directories. I think we can improve usabilities if users only need to change a config file. 2. Some applications may want to use two binding implementations at the same time. It seems to me that we will need a configuration somewhere to specify the specific binding implementation. Can we have a proprietary entry in scdl file sth like or ? (05:27:47) cr22rc: jboynes : I'm ok about taking it out .. but what are we looking for doing for samples needing axis wsbservice binding (05:28:44) jboynes: I want to package the axis binding as an extension that can be installed in the runtime (05:29:46) jboynes: so to run the sample you add the axis extension to your installation (05:30:43) ant: or we may have a distribution that includes axis right? (05:31:03) jboynes: sure (05:32:32) jboynes: I want to make sure that the basic concept (core + a bunch of extensions) works (05:33:19) kgoodson left the room (quit: Read error: 110 (Connection timed out)). (05:33:23) ant: could we talk about the ServletHost stuff now? (05:33:33) jboynes: so we don't end up in a situation where an extension only works if it is packed into a distro in a special way (05:33:40) jboynes: I need a couple more (05:33:48) jboynes: I need to eat (05:35:32) ant: ok, well ping when you're ready (05:48:04) jboynes: ant: hi, better now I've had breakfast :) (05:48:30) ant: yum (05:48:31) jboynes: sorry for holding things up - I just reached the pass out or get cranky phase (05:48:48) dkulp left the room (quit: "using sirc version 2.211+KSIRC/1.3.12"). (05:49:19) ant: ok so there's an interface ServletHost (05:50:02) jboynes: yep (05:50:10) ant: so the WS binding should use that to register a servlet for each ws endpoint -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build break
I am getting the following error trying to build revision: 431472 ... [surefire] testWSDLLocation(org.apache.tuscany.container.javascript.RhinoScriptI ntrospectorTestCase) Time elapsed: 0.02 sec <<< ERROR! java.lang.RuntimeException: WSDLException: faultCode=OTHER_ERROR: Unable to reso lve imported document at 'src/test/resources/org/apache/tuscany/container/javasc ript/rhino/helloworld.wsdl'.: This file was not found: file:/C:/apacheSVN/java/s rc/test/resources/org/apache/tuscany/container/javascript/rhino/helloworld.wsdl: java.io.FileNotFoundException: This file was not found: file:/C:/apacheSVN/java /src/test/resources/org/apache/tuscany/container/javascript/rhino/helloworld.wsd l at com.ibm.wsdl.util.StringUtils.getContentAsInputStream(Unknown Source) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.tuscany.container.javascript.JavaScriptIntrospector.readWS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OSGi based SCA container
Hi Joel, Sorry I didn't get to commit this yet. I got stuck first day back and will get to it ASAP. Jim On Aug 14, 2006, at 12:35 PM, Hawkins, Joel wrote: Hi Nicole. For OSGi, check out http://issues.apache.org/jira/browse/TUSCANY-610. I'd be interested in hearing your ideas about OSGi requirements. Cheers, Joel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 3:04 PM To: tuscany-dev@ws.apache.org Subject: OSGi based SCA container Hi, I started today having a look to the SCA examples and I would like to thank you for providing all the examples and documentation. It was a very good starting point :-) In addition I had a look to the Tuscany Developer Mailing List archive and I found some entries talking about OSGi which I would like to discuss with you. From my understanding (please correct me if I'm wrong) it's currently possible to use: -Tuscany standalone (e.g. HelloWorld example) -together with Tomcat (e.g. to use the SOAP binding) -or together with Celix (e.g. for the JMS example) If I would define a binding for OSGi or use the WebService Binding, it should be possible to invoke an OSGi based service (e.g. running in Equinox with the SOAP bundle) via Tuscany. But what's currently missing is the integration with existing component frameworks like EJB and OSGi. If I have an EJB (or OSGi service) with its deployment descriptor or annotations, Business Delegates and Skeletons there is no mechanism to map the SCA external service/entry point to the existing Business Delegates and Skeletons. Is this right or do you have already some ideas how to solve the integration? I would like to use an OSGi container with e.g. an EJB, BPEL and Servlet OSGi bundle. For the communication between these technologies as well as for the communication from/to the outside (e.g. entry points and external services) I would like to use SCA. Are we going to develop Tuscany in this direction? What are your thoughts on this topic? Thank you very much and best regards Nicole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - 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: OSGi based SCA container
On Aug 14, 2006, at 12:04 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Hi, I started today having a look to the SCA examples and I would like to thank you for providing all the examples and documentation. It was a very good starting point :-) In addition I had a look to the Tuscany Developer Mailing List archive and I found some entries talking about OSGi which I would like to discuss with you. From my understanding (please correct me if I'm wrong) it's currently possible to use: -Tuscany standalone (e.g. HelloWorld example) -together with Tomcat (e.g. to use the SOAP binding) -or together with Celix (e.g. for the JMS example) If I would define a binding for OSGi or use the WebService Binding, it should be possible to invoke an OSGi based service (e.g. running in Equinox with the SOAP bundle) via Tuscany. But what's currently missing is the integration with existing component frameworks like EJB and OSGi. If I have an EJB (or OSGi service) with its deployment descriptor or annotations, Business Delegates and Skeletons there is no mechanism to map the SCA external service/entry point to the existing Business Delegates and Skeletons. This is currently being worked on by the SCA spec group. Some early whitepapers on the approaches can be found at: http://www.osoa.org/ display/Main/SCA+Resources Is this right or do you have already some ideas how to solve the integration? I think the best way to approach this is through a binding or implementation type, depending on the circumstance and technology. For example, BPEL would be a component implementation type. I would like to use an OSGi container with e.g. an EJB, BPEL and Servlet OSGi bundle. For the communication between these technologies as well as for the communication from/to the outside (e.g. entry points and external services) I would like to use SCA. Joel has contributed an OSGi integration with Tuscany so it would be possible, for example, to have Tuscany consume OSGi services from a host environment such as Equinox, for example an HTTP service. Implementing a BPEL component type involves a more specific contract with Tuscany and we have an extension mechanism for that. Hope this helps. Jim Are we going to develop Tuscany in this direction? What are your thoughts on this topic? Thank you very much and best regards Nicole - 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: Adding an interceptor before InvokerInterceptor
On Aug 14, 2006, at 11:49 AM, Raymond Feng wrote: Hi, I ran into an issue adding an interceptor to the inbound invocation chain. The "JDKWireService" automatically adds an "InvokerInterceptor" to the inbound invocation chain when it creates wires. InvocationChain SPI only provides a method addInterceptor() which always try to append the interceptor. But "InvokerInterceptor" has to be the last interceptor in the chain and I'm getting IllegalStateException as it's coded in InvokerInterceptor. I can hack the JDKWireService to add my interceptor but it seems to be not ideal. Any other options? We need to get the policy registry hooked in to handle this. An policy builder would add the interceptor before the InvokerInterceptor is added. I posted on how this would be done last week if you want to take a shot at it. Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Finally posted: src file header and copyright policy
Hi Jeremy I have done necessary updates on das and sample/das files and provided a patch to http://issues.apache.org/jira/browse/TUSCANY-620. I'm having some issues around running the perl script to update the xml resources and will try to finish those tomorrow - Luciano On 7/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: On Jul 19, 2006, at 11:50 AM, Jeremy Boynes wrote: > Is this is good time to do this to the trunk (thinking that most > people will not have any work that will conflict)? > > I'll see if the tools work and if there are no issues think about > doing this later this week. We had a problem with some of the files not having license headers in them :-( so I modified Roy's script to be a little more aggressive and replace everything before the "package" statement with the new header. I ran these on a few files and they seemed to do the right thing but additional review would be appreciated. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Luciano Resende SOA Opensource - Apache Tuscany -
[jira] Updated: (TUSCANY-620) Update DAS headers and copyright policies
[ http://issues.apache.org/jira/browse/TUSCANY-620?page=all ] Luciano Resende updated TUSCANY-620: Attachment: lresende.patch.java.asj.headers.20060814.txt I have updated all java files from DAS and samples\DAS projects. I'll add a new patch for the xml resources once I figure out why the perl script is not working propertly on the xml files. > Update DAS headers and copyright policies > - > > Key: TUSCANY-620 > URL: http://issues.apache.org/jira/browse/TUSCANY-620 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: lresende.patch.java.asj.headers.20060814.txt > > > Need to update DAS source files with updated header and copyright policies > from ASF, see thread initiated by jboynes : > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/thrd6.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-620) Update DAS headers and copyright policies
Update DAS headers and copyright policies - Key: TUSCANY-620 URL: http://issues.apache.org/jira/browse/TUSCANY-620 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Critical Fix For: Java-M2 Need to update DAS source files with updated header and copyright policies from ASF, see thread initiated by jboynes : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/thrd6.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Module restructuring for classloader changes
For TUSCANY-619 I am going to move some of the function currently in core into separate modules so that we can get the classloader isolation right. The goal here is to break the modules down into four categories: 1) core runtime (spi, core) and dependencies 2) extensions (containers, bindings, data-bindings, idl, ...) 3) host implementations 4) api and bootstrap jars Of these, only ones from the last category would appear on an application's classpath. These would be things like the standard SCA API classes, Tuscany-specific API classes, and a few classes that might be needed to boot the SCA runtime. Examples of these would be the current launcher module and the webapp module I recently added. These jars will be very small and will really need to stand on their own (i.e. they will have no dependencies that may conflict with application code). The bootstrap code will reflectively load a host implementation using a isolated classloader and this will go on to boot the core runtime and then that will load its extensions. So the simple command line launcher would work like follows: * launcher.jar is run from the command line. * It will build a boot classpath comprising all jars in the "boot" directory. This will be the host and core runtime jars * It will create a host component (reflectively) and set up any parameters (such as the path to the install directory) * It will reflectively invoke the host's boot method * The host will create the runtime and deploy the system scdl * The system scdl may define an extension mechanism (e.g. a DirectoryScanExtender component) and then that would load extensions * The launcher will locate the application to launch and reflectively invoke the host's deploy method passing the URL * The host will construct the SCA config artifacts needed and use the runtime to deploy the application * The launcher will invoke the unmanaged application code's main() method * When the application exits the launcher will reflectively invoke the host to shut the runtime down For the webapp host the behaviour would similar: * the api and webapp bootstrap jars are added to the webapp classpath (in WEB-INF/lib or in an appserver directory) * a context listener is added to web.xml which will fire a bootstrapper in the webapp module * the bootstrapper will build a boot classpath from a resource in the webapp (or possibly from an external directory) * it will create a host, boot the runtime and deploy the application in the same way the launcher did * a TuscanyServlet (from the webapp bootstrap) will locate the ServletHost and forward requests into the runtime (e.g. for bound Services) * when the webapp shuts down, the context listener will shut down the runtime Application code will be loaded using a classloader that contains the following classes: * ones from the component implementation which will either be the composite's classloader or a child of it * classes the implementation chooses to make available (e.g. the JS container may make the Rhino classes available) * classes from the Thread context classloader supplied by the host when it invoked Tuscany This classloader will also be set as the Thread context classloader. This means that for normal application code Thread.getContextClassLoader() == getClass().getClassLoader(). It also means that, through delegation, classes from the original Thread context classloader supplied on invocation are available to host libraries. Extension code will be loaded using a classloader with the following: * classes from composite providing the extension Specifically, the Thread context classloader supplied by the host will not be modified. This means that extension code can assume that the Thread context classloader will always refer to application classes as specified above. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SDO] Hierarchical TypeHelper support for recursive composite model?
Normally, there're several ways to associate two things. 1. Registry such as WeakKeyMap Before SDO parties reach an agreement to provide a registry service (ever), SCA potentially can implement the registry (for the time being) 2. Direct link from Composite to TypeHelper, e.g. Composite#getTypeHelper() On 8/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, We're looking into the integration of SDO and Axis2 for the web service binding. One issue coming into the picture again is that how we maintain a hierachy of SDO TypeHelpers corresponding to the recursive composite model so that SCA artifacts in each level will have their view to the SDO typing system. I remember there were quite a few discussions related to this requirement before on this list. Do we have anything in place that I can leverage? Thanks, Raymond -- Yang ZHONG
[jira] Created: (TUSCANY-619) Fix classloader hierarchy for extensions
Fix classloader hierarchy for extensions Key: TUSCANY-619 URL: http://issues.apache.org/jira/browse/TUSCANY-619 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Reporter: Jeremy Boynes Assigned To: Jeremy Boynes We have the start of a classloader hierarchy working for extension code but it is not being set up correctly in some environments e.g. the current web launcher. This is causing problems when loading extensions such as Axis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn properties
Hi Jeremy, Here is the "auto-props" section of my Subversion config file (after correcting from "Rev, Date"): ### Section for configuring automatic properties. [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg Makefile = svn:eol-style=native *.java = svn:eol-style=native;svn:keywords=Rev Date *.xml = svn:eol-style=native;svn:keywords=Rev Date *.xsd = svn:eol-style=native;svn:keywords=Rev Date *.html = svn:eol-style=native;svn:keywords=Rev Date *.properties = svn:eol-style=native;svn:keywords=Rev Date *.jelly = svn:eol-style=native;svn:keywords=Rev Date *.ipr = svn:eol-style=native *.iml = svn:eol-style=native Is this correct? If so, I'll add this info for committers somewhere on our website or wiki. Thanks, --Kevin Jeremy Boynes wrote: I've just wasted an hour or so working with Raymond trying to figure out why a patch he supplied would not apply. I am writing this in a suitably frustrated mood ... It appears that there are many many files in our svn tree that do not have the correct properties set. Some files are missing the "svn:eol-style=native" setting which means files are being checked in with inconsistent line endings. Specifically, there are a lot of files with DOS "\r\n" endings which don't work so well for those of us not using Windows. There are also quite a few with svn:keywords set to "Rev,Date" as opposed to the correct value "Rev Date" meaning the date/version info is not being updated. I would ask everyone to double, triple check their SVN settings to make sure that they have the appropriate auto-properties configured. I am going to waste yet more time fixing the java/samples and java/ sca trees so we don't waste even more time in the future Can someone please spend the time to fix the java/sdo tree -- 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]
callbacks transcript from today
[12:24pm] jmarino: sorry you pinged before? [12:25pm] isilval__: yeah, I want to try to get on the same page wrt CompositeReference, its binding, wiring and connections prior to getting callbacks for the local via reference case [12:26pm] jmarino: k [12:27pm] isilval__: don't know if you saw my note asking about bindings for composite references [12:27pm] jmarino: not yet - let me read it for a sec [12:27pm] isilval__: it's just a couple of paras [12:28pm] jmarino: k so in sca there is a concept of an SCA "default" binding that can act remotely. I think this is different, it's a "composite binding" [12:30pm] isilval__: that sounds agreeable, but (as rfeng also seems to be asking about) it seems like a CompositeReference object would need a binding in order for the builder to add it the CompositeComponent that contains it [12:30pm] jmarino: this means we would have some type of reference entry and a binding entry that would point to the target address. The binding could be set either in the SCDL directly or in the use of the composite [12:31pm] jboynes: is this a different type of "default" binding? [12:31pm] isilval__: by reference entry do you mean the SCAObject? [12:31pm] jboynes: I mean, if there is no element, do we supply a default? [12:32pm] jboynes: and what is the difference between no and ? [12:32pm] isilval__: the way I understand binding.sca is as a proprietary implementation of a remote binding [12:33pm] isilval__: so it sounds reasonable not to use in this case [12:33pm] isilval__: but I may be wrong [12:33pm] jmarino: yes it is a proprietary implementation of a binding [12:33pm] jmarino: we could however say we also support a "proprietary" composite binding as well [12:34pm] isilval__: a remote one, more specifically [12:34pm] jmarino: in that case we need to be able to express a target uri [12:35pm] jboynes: where would you use this? [12:35pm] isilval__: unless the component whose implementation the composite that contains the reference is resolves the target [12:35pm] jboynes: yes [12:36pm] jboynes: (that was a hard one to parse) [12:36pm] isilval__: sorry ... [12:36pm] jboynes: [12:37pm] mdinges left the chat room. [12:37pm] jmarino: on ingacio's point, we always go through a reference in the child [12:37pm] jmarino: the reference needs to point to some target at some point, e.g. the binding could be set in the parent [12:38pm] isilval__: the parent being the hard to parse component? [12:39pm] jboynes: [12:39pm] jmarino: I think we have two composites, a parent and a child [12:39pm] jmarino: the child contains a component and a reference [12:39pm] jboynes: ah, confusion over parent [12:40pm] jmarino: the component in the child is wired to a reference in the child [12:40pm] isilval__: with you so far [12:40pm] jmarino: the reference is wired to something else [12:40pm] isilval__: the reference in the child does not have a target [12:40pm] jboynes: the reference is not wired [12:40pm] jmarino: k then it needs to be wired in the parent [12:41pm] jmarino: all references must be satisfied at some point [12:41pm] isilval__: presumably the parent resolves the reference? [12:41pm] jboynes: the component in the parent composite that is implemented by the child composite defines the target for the reference in the cild [12:41pm] jmarino: there needs to be a wire in the parent or some way to satisfy the reference [12:41pm] jmarino: yes [12:42pm] jboynes: equally hard to parse [12:42pm] isilval__: yes [12:42pm] isilval__: [12:42pm] jmarino: k so we're on that page [12:43pm] isilval__: so we need a separate mechanism to generate a BoundReference for the targetless reference [12:43pm] isilval__: or will we not even call it a BoundReference? [12:43pm] jmarino: at some point the loaders have to set the target [12:44pm] jboynes: i don't think it's a BoundReference [12:44pm] jmarino: the wiring infrastructure I don't think should have special cases in it if possible [12:44pm] jboynes: the component will have a ReferenceTarget [12:44pm] isilval__: right now the connector only recognizes BoundReferences [12:45pm] jboynes: the ReferenceTarget will define the target for the Reference in the componenttype [12:45pm] isilval__: and it thinks the alternative (ie, ReferenceDefinitions) are references on atomic components [12:46pm] isilval__: need to step out for a min [12:47pm] jmarino: I think we may be talking about different things again [12:47pm] lresende: jboynes: is there any tools to update all headers on a specific tree ? [12:47pm] jboynes: maybe - I think there is confusion and a lack of clarity here [12:48pm] jboynes: lresende: look in etc [12:48pm] jmarino: I see this child component>reference> (binding)--->target in parent [12:48pm] jboynes: addLicense2java.pl [12:48pm] jboynes: give it a list of java source files to crunch [12:49pm] jboynes: jmarino: I don't grok [12:50pm] jboynes: are you talking about how its c
Re: Running Samples in Eclipse
Hi Kapish, Are you using M1 or the current source?
[SDO] Hierarchical TypeHelper support for recursive composite model?
Hi, We're looking into the integration of SDO and Axis2 for the web service binding. One issue coming into the picture again is that how we maintain a hierachy of SDO TypeHelpers corresponding to the recursive composite model so that SCA artifacts in each level will have their view to the SDO typing system. I remember there were quite a few discussions related to this requirement before on this list. Do we have anything in place that I can leverage? Thanks, Raymond
Re: Default SCA binding for services/references
I also assume that default SCA binding should be very easy to configure. 1) For the service side, a simple should be good enough. The runtime should expose it to a prefered protocol (for example) at an endpoint whose address can be derived from the composite/service naming system. 2) For the reference side, the URI will point to the target service by the composite/service hierarchy. The contract between a reference and a service with SCA default binding should be transparent to application developers. Thanks, Raymond - Original Message - From: "Andrew Borley" <[EMAIL PROTECTED]> To: Sent: Monday, August 14, 2006 1:09 PM Subject: Re: Default SCA binding for services/references Hi Raymond, I think one of things that the SCA binding should do is enable interop between the Java and C++ Tuscany runtimes, perhaps just on the local system. Obviously web services is one way of doing this (and probably the best, as it also enables remote system interop) but if anyone wants to think about using/find a more performant method I'd be interested in working on the C++ side of things. Cheers Andy On 8/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The SCA spec has a notion of default SCA binding for services and references (An XML tag "binding.sca" is defined in SCDL). If I understand correctly, it can a vendor's choice of which protocol will be used as the deault. What's the tuscany position on this? Do we use "web service" as the default binding? The only thing I can tell at this moment is that cannot be recognized by our loaders. Thanks, Raymond - 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: Default SCA binding for services/references
Hi Raymond, I think one of things that the SCA binding should do is enable interop between the Java and C++ Tuscany runtimes, perhaps just on the local system. Obviously web services is one way of doing this (and probably the best, as it also enables remote system interop) but if anyone wants to think about using/find a more performant method I'd be interested in working on the C++ side of things. Cheers Andy On 8/14/06, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, The SCA spec has a notion of default SCA binding for services and references (An XML tag "binding.sca" is defined in SCDL). If I understand correctly, it can a vendor's choice of which protocol will be used as the deault. What's the tuscany position on this? Do we use "web service" as the default binding? The only thing I can tell at this moment is that cannot be recognized by our loaders. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OSGi based SCA container
Hi Nicole. For OSGi, check out http://issues.apache.org/jira/browse/TUSCANY-610. I'd be interested in hearing your ideas about OSGi requirements. Cheers, Joel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 3:04 PM To: tuscany-dev@ws.apache.org Subject: OSGi based SCA container Hi, I started today having a look to the SCA examples and I would like to thank you for providing all the examples and documentation. It was a very good starting point :-) In addition I had a look to the Tuscany Developer Mailing List archive and I found some entries talking about OSGi which I would like to discuss with you. >From my understanding (please correct me if I'm wrong) it's currently possible to use: -Tuscany standalone (e.g. HelloWorld example) -together with Tomcat (e.g. to use the SOAP binding) -or together with Celix (e.g. for the JMS example) If I would define a binding for OSGi or use the WebService Binding, it should be possible to invoke an OSGi based service (e.g. running in Equinox with the SOAP bundle) via Tuscany. But what's currently missing is the integration with existing component frameworks like EJB and OSGi. If I have an EJB (or OSGi service) with its deployment descriptor or annotations, Business Delegates and Skeletons there is no mechanism to map the SCA external service/entry point to the existing Business Delegates and Skeletons. Is this right or do you have already some ideas how to solve the integration? I would like to use an OSGi container with e.g. an EJB, BPEL and Servlet OSGi bundle. For the communication between these technologies as well as for the communication from/to the outside (e.g. entry points and external services) I would like to use SCA. Are we going to develop Tuscany in this direction? What are your thoughts on this topic? Thank you very much and best regards Nicole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OSGi based SCA container
Hi, I started today having a look to the SCA examples and I would like to thank you for providing all the examples and documentation. It was a very good starting point :-) In addition I had a look to the Tuscany Developer Mailing List archive and I found some entries talking about OSGi which I would like to discuss with you. >From my understanding (please correct me if I'm wrong) it's currently >possible to use: -Tuscany standalone (e.g. HelloWorld example) -together with Tomcat (e.g. to use the SOAP binding) -or together with Celix (e.g. for the JMS example) If I would define a binding for OSGi or use the WebService Binding, it should be possible to invoke an OSGi based service (e.g. running in Equinox with the SOAP bundle) via Tuscany. But what's currently missing is the integration with existing component frameworks like EJB and OSGi. If I have an EJB (or OSGi service) with its deployment descriptor or annotations, Business Delegates and Skeletons there is no mechanism to map the SCA external service/entry point to the existing Business Delegates and Skeletons. Is this right or do you have already some ideas how to solve the integration? I would like to use an OSGi container with e.g. an EJB, BPEL and Servlet OSGi bundle. For the communication between these technologies as well as for the communication from/to the outside (e.g. entry points and external services) I would like to use SCA. Are we going to develop Tuscany in this direction? What are your thoughts on this topic? Thank you very much and best regards Nicole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-618) DAS Modular Distribution
[ http://issues.apache.org/jira/browse/TUSCANY-618?page=all ] Luciano Resende updated TUSCANY-618: Attachment: lresende.das.distribution.20060814.zip patch in zip format containing das modular distribution. this should go under java/distribution > DAS Modular Distribution > > > Key: TUSCANY-618 > URL: http://issues.apache.org/jira/browse/TUSCANY-618 > Project: Tuscany > Issue Type: New Feature > Components: Java DAS RDB >Affects Versions: Java-M2 >Reporter: Luciano Resende > Assigned To: Luciano Resende >Priority: Critical > Fix For: Java-M2 > > Attachments: lresende.das.distribution.20060814.zip > > > Need to provide modular distribution for DAS component under Tuscany -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-618) DAS Modular Distribution
DAS Modular Distribution Key: TUSCANY-618 URL: http://issues.apache.org/jira/browse/TUSCANY-618 Project: Tuscany Issue Type: New Feature Components: Java DAS RDB Affects Versions: Java-M2 Reporter: Luciano Resende Assigned To: Luciano Resende Priority: Critical Fix For: Java-M2 Need to provide modular distribution for DAS component under Tuscany -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding an interceptor before InvokerInterceptor
Hi, I ran into an issue adding an interceptor to the inbound invocation chain. The "JDKWireService" automatically adds an "InvokerInterceptor" to the inbound invocation chain when it creates wires. InvocationChain SPI only provides a method addInterceptor() which always try to append the interceptor. But "InvokerInterceptor" has to be the last interceptor in the chain and I'm getting IllegalStateException as it's coded in InvokerInterceptor. I can hack the JDKWireService to add my interceptor but it seems to be not ideal. Any other options? Thanks, Raymond
Default SCA binding for services/references
Hi, The SCA spec has a notion of default SCA binding for services and references (An XML tag "binding.sca" is defined in SCDL). If I understand correctly, it can a vendor's choice of which protocol will be used as the deault. What's the tuscany position on this? Do we use "web service" as the default binding? The only thing I can tell at this moment is that cannot be recognized by our loaders. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Name for the application composite?
So basically, we have an "application" component in "tuscany.root" composite and the component is implemented by the composite represented by the SCDL. Right? Here's the hierarchy I figured out from the debugger. Please confirm. tuscany.runtime --- tuscany.system --- tuscany.system --- (all the extension components) --- RuntimeInfo --- tuscany.root --- application (implemented by a composite provided by the user application) Thanks, Raymond - Original Message - From: "Jeremy Boynes" <[EMAIL PROTECTED]> To: Sent: Monday, August 14, 2006 11:15 AM Subject: Re: Name for the application composite? Yes, the name in the attribute is the name of the composite not the name for the component. The "application" name is only used by the launcher as it, by design, only deploys a single application; it would be possible to derive the name somehow e.g. from the file name. If you look at the servlet version it uses the name of the webapp as the name for the component. -- Jeremy On Aug 14, 2006, at 10:59 AM, Raymond Feng wrote: Hi, I noticed that when we deploy an application, the corresponding name for the CompositeComponent is hard-coded as "application" rather than loaded from the name attribute in the SCDL file. Is it by design? Thanks, Raymond - 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: Name for the application composite?
Yes, the name in the attribute is the name of the composite not the name for the component. The "application" name is only used by the launcher as it, by design, only deploys a single application; it would be possible to derive the name somehow e.g. from the file name. If you look at the servlet version it uses the name of the webapp as the name for the component. -- Jeremy On Aug 14, 2006, at 10:59 AM, Raymond Feng wrote: Hi, I noticed that when we deploy an application, the corresponding name for the CompositeComponent is hard-coded as "application" rather than loaded from the name attribute in the SCDL file. Is it by design? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Name for the application composite?
Hi, I noticed that when we deploy an application, the corresponding name for the CompositeComponent is hard-coded as "application" rather than loaded from the name attribute in the SCDL file. Is it by design? Thanks, Raymond
Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks
- Original Message - From: "Jim Marino" <[EMAIL PROTECTED]> To: Sent: Friday, August 11, 2006 4:59 PM Subject: Re: [jira] Updated: (TUSCANY-585) Initial support for callbacks On Aug 11, 2006, at 11:58 AM, Jeremy Boynes wrote: I have a feeling there may be some confusion here with terminology - heck, I know I'm confused :-) Yes, I think it is a terminology thing. I was thinking of the three scenarios below and local only being a case of #1. I think there are several scenarios here and would like to make sure they are all being covered. 1) Component->Component - this must lie within a Composite and may have local or remote semantics 2) Component->Reference with remote Binding - the wire lies within a Composite and disappears into the remote binding 3) Component->Reference wired by the Composite - there is a local wire between the Component and the Reference and an external wire from the CompositeComponent to a sibling Component or Reference (aka the "uncle") I believe cases 1) and 2) are well covered. A target SCAObject is created with an inbound wire which is then connected to an outbound wire from the source. The resulting connection may be optimized away, or may have policy or other interceptors applied. Yes but #2 still need to be done. I am confused about how case 3) is being handled, specifically how the connection is being made between the Reference and the CompositeComponent. I think there is a good case to me made for having an SCAObject to represent the Reference - for example, you may want to manage the reference in some way. Having it there does not mean that it needs to be part of the invocation path. For example, during connection the wire could be optimized in a way that allowed the "uncle" to be directly injected into the source. Perhaps "JavaReference" is confusing here - how about we call it a "CompositeReference", as in "a Reference whose wiring is handled by the composite component that contains it." This would work in conjunction with a CompositeComponent to pass wires around - for example, CompositeComponent.addOutboundWire could just delegate down to the appropriate CompositeReference (selected by name). Yes having the special type of reference makes sense because this is a type of binding. The target invoker in this case could actually be an interceptor which flowed the invocation to the head interceptor of the uncle. If this is the case, we may need to have the Connector handle this case of finding the target in the outer "grandparent" composite (if that makes sense). So, if a CompositeReference is a type of binding then it needs to define a Binding subclass, a BindingBuilder and a BindingLoader, for which an XMLType needs to be defined. What would this be, binding.sca, would it be implicit. If it is implicit, how does the corresponding BindingBuilder know that a CompositeReference is being built? The interceptor realization of the target invoker seems a bit mysterious to me, can you elaborate a bit? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-617) Celtix binding improvment and a Celtix binding version of helloworld sample
[ http://issues.apache.org/jira/browse/TUSCANY-617?page=comments#action_12427935 ] Jervis Liu commented on TUSCANY-617: For the time being, we need a hack in order to run helloworldws-celtix sample. You need to edit distribution\sca\standalone\pom.xml and distribution\sca\standalone\src\main\assembly\standalone.xml, change any appearance of axis2 to celtix. I will create a seperate jira issue on how to properly create distribution for different bindings. > Celtix binding improvment and a Celtix binding version of helloworld sample > --- > > Key: TUSCANY-617 > URL: http://issues.apache.org/jira/browse/TUSCANY-617 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Celtix Binding >Reporter: Jervis Liu > Attachments: jira_617.patch > > > Added a Celtix version of helloworldws sample > Improved Celtix binding code: initialize Celtix bus > Fixed a problem in DirectoryScanExtender.java: should not try to load a > component from jars under extension dir that do not contain a valid scdl file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] Celtix binding improvement and helloworldws sample
Hi, Can someone kindly review and apply patch for jira 617 please. https://issues.apache.org/jira/browse/TUSCANY-617. In this patch: 1. Added a Celtix version of helloworldws sample 2. Improved Celtix binding code: initialize Celtix bus 3. Fixed a problem in DirectoryScanExtender.java: should not try to load a component from jars under extension dir that do not contain a valid scdl file For the time being, we need a hack in order to run helloworldws-celtix sample. You need to edit distribution\sca\standalone\pom.xml and distribution\sca\standalone\src\main\assembly\standalone.xml, change any appearance of axis2 to celtix. I will create a seperate jira issue on how to properly create distribution for different bindings. Thanks, Jervis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-617) Celtix binding improvment and a Celtix binding version of helloworld sample
[ http://issues.apache.org/jira/browse/TUSCANY-617?page=all ] Jervis Liu updated TUSCANY-617: --- Attachment: jira_617.patch > Celtix binding improvment and a Celtix binding version of helloworld sample > --- > > Key: TUSCANY-617 > URL: http://issues.apache.org/jira/browse/TUSCANY-617 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Celtix Binding >Reporter: Jervis Liu > Attachments: jira_617.patch > > > Added a Celtix version of helloworldws sample > Improved Celtix binding code: initialize Celtix bus > Fixed a problem in DirectoryScanExtender.java: should not try to load a > component from jars under extension dir that do not contain a valid scdl file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-617) Celtix binding improvment and a Celtix binding version of helloworld sample
Celtix binding improvment and a Celtix binding version of helloworld sample Key: TUSCANY-617 URL: http://issues.apache.org/jira/browse/TUSCANY-617 Project: Tuscany Issue Type: Improvement Components: Java SCA Celtix Binding Reporter: Jervis Liu Attachments: jira_617.patch Added a Celtix version of helloworldws sample Improved Celtix binding code: initialize Celtix bus Fixed a problem in DirectoryScanExtender.java: should not try to load a component from jars under extension dir that do not contain a valid scdl file -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (TUSCANY-611) RMI Binding
On Aug 13, 2006, at 11:00 PM, Jeremy Boynes wrote: On Aug 13, 2006, at 10:42 PM, Venkata Krishnan wrote: - each registry is identified by a port on which it runs. I am not sure how hostname can be used for services. However, for references host names has a role to play. Right? For services it would determine the address that the port would apply to. The default (0.0.0.0) would be all addresses on the machine but for multi-homed machines it is quite often useful to be able to specify a particular interface. - RMI Host will be the interface thro which RMIBinding will register services into one of the registries (based on the port number specified) Can you please point me to some code that I can emulate to implement RMI Host in terms of how it should be implemented as a system component that can be autowired into the builder. Right now I am looking at LoaderRegistry to understand the programming model for this. Am I on track? That's as good as any. If you start with a POJO and just decorate it according its methods with @Init and/or @Destroy as needed you should have most of it. I'll keep an eye out and help when needed. Jim -- 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]
[C++] SCA Extensions
Hi All,
I've been thinking a bit more about how we could do extensions.
Specifically, I've been working through what would be needed to add a new
component language binding in to Tuscany. I'm basing this on adding support
for components written in Python, as this is a language that is widely used,
extensible, embeddable and includes introspection.
To call a method in a Python module all we would need in the .composite file
is something like the following information:
The Python module will be in a file at
"/path/to/python/module/DivideModule.py" and would have a method that
implements a divide operation.
Python's introspection can find the correct method and describe the method
arguments and return types, so there is no requirement for code generated
via SCAGEN here (other languages may well need generated code).
We therefore need a way to extend the assembly model with the <
implementation.python> element and a way to extend Tuscany so that when it
finds an element, it knows to call a library that
will invoke the Python code.
So to list things out we need to:
1) Define extensions for Tuscany in some way - perhaps a "Tuscany.config"
file that could have a schema like:
*
*
some-parameter-value
So for example, a Python component langauge implementation extension like
this:
/path/to/python/installation
would have a library named
/path/to/python/tuscany/extension/library/libtuscany-python.so and a schema
to define the element at
/path/to/python/tuscany/extension/library/xsd/tuscany-impl-python.xsd. The
library would be initialised with a parameter named pythonroot with value
/path/to/python/installation.
2) Tuscany will need changing to:
a) register any schemas named in the "Tuscany.config" file
b) when the .composite files are read, notice the
element and load and initialise the specified extension library with the
contents of the element and the parameters from the
"Tuscany.config" file
c) when the component is invoked, call the extension library with a
tuscany::sca::Operation object. The extension will find the appropriate
operation in the Python module, find the parameter and return types that the
operation expects, map the C++ types to Python types, invoke the operation
and finally map the return type from Python to C++.
3) Create an extension to Python that will add support for invoking
references from Python components.
e.g. enable the Python equivalent of:
// Get the current ComponentContext
osoa::sca::ComponentContext myContext =
osoa::sca::ComponentContext::getCurrent();
// Find the required service, as referenced in
CalculatorImpl.componentType
DivideService* divideService =
(DivideService*)myContext.getService("divideService");
// Finally, invoke the service
result = divideService->divide(arg1, arg2);
How does this sound as a start to enabling some extensions in SCACPP?
I'm happy to get going implementing this, but it may be worth me working in
a branch as there'll be lots of changes (& I don't yet have my committer
access).
Cheers
Andrew
Running Samples in Eclipse
Hey, I was curious if there were any updated or more detailed instructions in running the samples in Eclipse. I'm fairly new and am trying to run Hello World sample in Eclipse. Any help would be appreciated. Thanks. Kapish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IDE Plugins
Hi, I have been trying to run the samples (not the test cases) from Eclipse with limited success. I was thinking about the value of having an Eclipse plugin that would allow defining and validating SCDL and defining run configurations that can bootstrap standalone Tuscany runtimes. Has anyone got any thoughts on this? Ta Meeraj * You can find us at www.voca.com * This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Patches TUSCANY-606 and 613, was: BigBank scenario working end to end
patch applied On 14/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote: No problem, I've put a new patch up at TUSCANY-613 from the latest code revision. This includes the 606 update, so no need to update that one. Cheers Andy On 8/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Andrew Borley wrote: > [snip] > > I needed to update the deploy.bat file that puts the various files in > > the right places in the samples/BigBank/deploy directory so I've put a > > patch up at TUSCANY-606. > > > Andy, > > I am not able to apply patch TUSCANY-606 (and similar problem with > TUSCANY-613). > > patch -p0 gives me this error: > (Stripping trailing CRs from patch.) > patching file sca/samples/BigBank/deploy.bat > Hunk #1 FAILED at 1. > 1 out of 1 hunk FAILED -- saving rejects to file > sca/samples/BigBank/deploy.bat.rej > > I have no idea what "1 out of 1 hunk failed" means :) but svn info > deploy.bat tells me: Last Changed Rev 429833, and the patch was > generated on an earlier revision 429611... Could this be the problem? > > Sorry about the inconvenience but could you try svn up then svn diff > again and attach new patches to the JIRA issues? I'll try applying them > again... Thanks. > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete
[jira] Commented: (TUSCANY-606) BigBank deploy.bat file misplaces or misses out some files
[ http://issues.apache.org/jira/browse/TUSCANY-606?page=comments#action_12427851 ] Andrew Borley commented on TUSCANY-606: --- Patch at TUSCANY-613 supercedes this fix. This jira can be closed when 613 is. > BigBank deploy.bat file misplaces or misses out some files > -- > > Key: TUSCANY-606 > URL: http://issues.apache.org/jira/browse/TUSCANY-606 > Project: Tuscany > Issue Type: Bug > Components: C++ SCA >Affects Versions: Cpp-current > Environment: Windows >Reporter: Andrew Borley >Priority: Minor > Attachments: TUSCANY-606.patch > > > The sca/samples/BigBank/deploy.bat file needs updating to reflect Sebastiens > BigBank updates -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Patches TUSCANY-606 and 613, was: BigBank scenario working end to end
No problem, I've put a new patch up at TUSCANY-613 from the latest code revision. This includes the 606 update, so no need to update that one. Cheers Andy On 8/12/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Andrew Borley wrote: [snip] > I needed to update the deploy.bat file that puts the various files in > the right places in the samples/BigBank/deploy directory so I've put a > patch up at TUSCANY-606. > Andy, I am not able to apply patch TUSCANY-606 (and similar problem with TUSCANY-613). patch -p0
[jira] Updated: (TUSCANY-613) Move to 0.95 spec Assembly model
[ http://issues.apache.org/jira/browse/TUSCANY-613?page=all ] Andrew Borley updated TUSCANY-613: -- Attachment: TUSCANY-613-2.patch Patch 2 tries again - a possible issue with revision numbers when applying the previous patch > Move to 0.95 spec Assembly model > > > Key: TUSCANY-613 > URL: http://issues.apache.org/jira/browse/TUSCANY-613 > Project: Tuscany > Issue Type: New Feature > Components: C++ SCA >Affects Versions: Cpp-current >Reporter: Pete Robbins > Assigned To: Pete Robbins > Attachments: TUSCANY-613-2.patch, TUSCANY-613.patch > > > To cover work for composites etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-372) Null pointer for axis2/tomcat example where the service interface/operation takes no parameters
[ http://issues.apache.org/jira/browse/TUSCANY-372?page=all ] ant elder reassigned TUSCANY-372: - Assignee: (was: ant elder) > Null pointer for axis2/tomcat example where the service interface/operation > takes no parameters > --- > > Key: TUSCANY-372 > URL: http://issues.apache.org/jira/browse/TUSCANY-372 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding >Affects Versions: Java-Mx > Environment: Fedora Core 5 >Reporter: Simon Laws > Fix For: Java-Mx > > Attachments: helloworld6-notworkingsample.tar, > helloworld7-workingsample.tar > > > This is based on a check out from last week so I will give it a go on the > latest release but lest I forget the details. I have an example (attached) > which simply calls a remote component via axis2/web services. The implemented > operation takes no parameters and causes a null pointers exception down in > the Axis code on the server side where the request message is being unpacked > [1]. I copied the example and changed the operation signature to include a > single string parameter (also included) and all was well. Nothing else, as > far as I can tell, changed between the two versions of the sample. > [1] > [EMAIL PROTECTED] helloworld6client]$ ./run.sh > Exception in thread "main" org.osoa.sca.ServiceRuntimeException: > org.apache.axis2.AxisFault: null; nested exception is: > java.lang.NullPointerException > at > org.apache.tuscany.binding.axis2.externalservice.Axis2ServiceInvoker.invoke(Axis2ServiceInvoker.java:56) > at > org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.doInvoke(ExternalServiceTargetInvoker.java:84) > at > org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.invokeTarget(ExternalServiceTargetInvoker.java:79) > at > org.apache.tuscany.core.extension.ExternalServiceTargetInvoker.invoke(ExternalServiceTargetInvoker.java:93) > at > org.apache.tuscany.core.wire.impl.InvokerInterceptor.invoke(InvokerInterceptor.java:39) > at > org.apache.tuscany.core.wire.jdk.JDKInvocationHandler.invoke(JDKInvocationHandler.java:112) > at $Proxy13.getResponse(Unknown Source) > at > org.sample.helloworld.HelloWorldClient.main(HelloWorldClient.java:28) > Caused by: org.apache.axis2.AxisFault: null; nested exception is: > java.lang.NullPointerException > at > org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:287) > at > org.apache.tuscany.binding.axis2.externalservice.Axis2OperationInvoker.invokeOperation(Axis2OperationInvoker.java:78) > at > org.apache.tuscany.binding.axis2.externalservice.Axis2ServiceInvoker.invoke(Axis2ServiceInvoker.java:53) > ... 7 more > Caused by: java.lang.Exception: org.apache.axis2.AxisFault: null; nested > exception is: > java.lang.NullPointerException > at org.apache.axis2.AxisFault.makeFault(AxisFault.java:318) > at > org.apache.tuscany.binding.axis2.entrypoint.WebServiceEntryPointInOutSyncMessageReceiver.invokeBusinessLogic(WebServiceEntryPointInOutSyncMessageReceiver.java:83) > at > org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:37) > at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:454) > at > org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:284) > at > org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:136) > at > org.apache.tuscany.binding.axis2.entrypoint.WebServiceEntryPointServlet.doPost(WebServiceEntryPointServlet.java:81) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at org.apache.tuscany.tomcat.TuscanyValve.invoke(TuscanyValve.java:87) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Proc
[jira] Closed: (TUSCANY-317) Java SCA Groovy Container
[ http://issues.apache.org/jira/browse/TUSCANY-317?page=all ] ant elder closed TUSCANY-317. - Resolution: Fixed > Java SCA Groovy Container > - > > Key: TUSCANY-317 > URL: http://issues.apache.org/jira/browse/TUSCANY-317 > Project: Tuscany > Issue Type: New Feature >Affects Versions: Java-Mx >Reporter: Meeraj Kunnumpurath > Assigned To: ant elder >Priority: Minor > Fix For: Java-Mx > > Attachments: container.groovy.zip, container.groovy.zip > > > SCA Container for running Groovy scripts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-331) No maven plugin for Java2WSDL
[ http://issues.apache.org/jira/browse/TUSCANY-331?page=all ] ant elder reassigned TUSCANY-331: - Assignee: (was: ant elder) > No maven plugin for Java2WSDL > - > > Key: TUSCANY-331 > URL: http://issues.apache.org/jira/browse/TUSCANY-331 > Project: Tuscany > Issue Type: New Feature > Components: Java SCA Tools >Affects Versions: Java-Mx >Reporter: Rick Rineholt > Fix For: Java-Mx > > Attachments: Java2WSDL - Tuscany Patch 11-May.txt, > java2wsdl-mojo-pom-fragment.xml, SCA-Tools-Maven-Plugins.zip > > > There is no maven plugin for Java2WSDL as there is for SDO gen. and SCA gen. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Design of SCA and SDO public API classes
> A related question. What do you think about reorganizing the folder > > structure a little to clearly separate the spec includes from the > > implementation specific ones? > > yes that would make sense. The osoa/sca tree should only contain what is defined in the spec. Cheers,
Re: [C++] Design of SCA and SDO public API classes
That's about it. The SCA spec says that you actually get instances of e.g. ComponentContext so we need to delegate to the ComponentContextImpl. As SDO was returning pointers inheritence works fine. Cheers, On 14/08/06, Edward Slattery <[EMAIL PROTECTED]> wrote: In the case of SDO, it was just the logical pattern for implementation hiding. The implementation was fine up to the point where we wanted to start thinking about the static SDO api, and were proposing to allow code generators to inherit from some DataObject base class and add their own methods such as "getName()" etc. We cant do that with DataObject, as all the DataObject pointers given out are really DataObjectImpls. The prototype code I put in the test directory uses containment instead of inheritance to allow a MyDataObject to contain a reference to a DataObject, and delegate its DataObjectish behaviour. cheers, Ed. On 11/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > I noticed two different patterns in the definition of the public SCA and > SDO API classes. > > SCA: > A delegation pattern where the public API class delegates calls to an > implementation class. > For example ComponentContext contains a private pointer to > ComponentContextImpl. ComponentContextImpl implements the methods from > ComponentContext but does not extend ComponentContext. > > SDO: > Inheritance, where the implementation class extends the public API class. > For example DataFactoryImpl extends DataFactory. > > Is there any particular reason for the two different patterns? Any > advantages or issues with one compared the other? > > A related question. What do you think about reorganizing the folder > structure a little to clearly separate the spec includes from the > implementation specific ones? > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete
Re: [C++] Design of SCA and SDO public API classes
In the case of SDO, it was just the logical pattern for implementation hiding. The implementation was fine up to the point where we wanted to start thinking about the static SDO api, and were proposing to allow code generators to inherit from some DataObject base class and add their own methods such as "getName()" etc. We cant do that with DataObject, as all the DataObject pointers given out are really DataObjectImpls. The prototype code I put in the test directory uses containment instead of inheritance to allow a MyDataObject to contain a reference to a DataObject, and delegate its DataObjectish behaviour. cheers, Ed. On 11/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I noticed two different patterns in the definition of the public SCA and SDO API classes. SCA: A delegation pattern where the public API class delegates calls to an implementation class. For example ComponentContext contains a private pointer to ComponentContextImpl. ComponentContextImpl implements the methods from ComponentContext but does not extend ComponentContext. SDO: Inheritance, where the implementation class extends the public API class. For example DataFactoryImpl extends DataFactory. Is there any particular reason for the two different patterns? Any advantages or issues with one compared the other? A related question. What do you think about reorganizing the folder structure a little to clearly separate the spec includes from the implementation specific ones? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
