RE: Inheriting Wiring infrastructure
Well, now I know the boundaries of the Apache/Eclipse cross-licensing agreement. :-) The code in question is straight-forward reflection code to find and invoke a method (3 lines of code + exception handling). I use it to pull the ClassLoader out of a bundle context. I'll submit a fix to get rid of the EPL dependency. Cheers, Joel -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Wed 8/9/2006 5:16 PM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 9, 2006, at 9:32 AM, Hawkins, Joel wrote: > JIRA is in. Looking forward to working with Tuscany - lots to learn! > Thanks - quite a lot there, may take some time to grok it all. One immediate question though. Apache cannot accept EPL licensed items in source form due to the downstream requirements. How complex is the code in question and could you provide a description that would allow someone who has not seen it to re-implement under ASL (i.e. a work that was not a derivative)? -- Jeremy - 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]
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 9:32 AM, Hawkins, Joel wrote: JIRA is in. Looking forward to working with Tuscany - lots to learn! Thanks - quite a lot there, may take some time to grok it all. One immediate question though. Apache cannot accept EPL licensed items in source form due to the downstream requirements. How complex is the code in question and could you provide a description that would allow someone who has not seen it to re-implement under ASL (i.e. a work that was not a derivative)? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting Wiring infrastructure
Thanks Joel, will look that up soon. Meanwhile I've manage to pull of the RMI Binding with quite a few hacks around. I'll post it soon over a JIRA for others to take a look. Thanks - Venkat On 8/9/06, Hawkins, Joel <[EMAIL PROTECTED]> wrote: JIRA is in. Looking forward to working with Tuscany - lots to learn! Cheers, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 11:53 AM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 9, 2006, at 7:46 AM, Jeremy Boynes wrote: > On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: > >> Hello Jims (Venkata, and everyone else struggling with bindings, >> etc.) >> >> I have an OSGi binding implementation that's sort of working now >> (I can >> run the SupplyChain example in equinox, repackaged into a couple of >> bundles, etc). There's a binding.osgi that allows me to expose SCA >> services as OSGi services, and there's an implementation.osgi that >> allows me to consume OSGi services as SCA components. I'm sure >> it's not >> perfect, but it's a start. :-) > > Sounds like a pretty good start :-) > >> I've also got some OSGi-specific implementations of some of the >> boot-strappy classes for dealing with classloader issues and some >> manager code that allows sca applications (packaged as bundles) to >> run >> in separate contexts. > > :-) > >> I'd like to provide this code to Tuscany and help complete the >> implementation. How would you like me to proceed? Do you have time to >> look at it and point out where I've gone astray? > > Thank you. If you can create a JIRA and attach what you have as a > patch or zip archive I would suggest we check this in to the trunk > but do not include in the main build just yet. This sounds like a > cool and valuable contribution. Yea that would be great. If you can do that, I'll go in and clean out the old equinox project shell I started a while back. Good to hear from you again too. Jim > > 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] 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]
RE: Inheriting Wiring infrastructure
JIRA is in. Looking forward to working with Tuscany - lots to learn! Cheers, Joel -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 11:53 AM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 9, 2006, at 7:46 AM, Jeremy Boynes wrote: > On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: > >> Hello Jims (Venkata, and everyone else struggling with bindings, >> etc.) >> >> I have an OSGi binding implementation that's sort of working now >> (I can >> run the SupplyChain example in equinox, repackaged into a couple of >> bundles, etc). There's a binding.osgi that allows me to expose SCA >> services as OSGi services, and there's an implementation.osgi that >> allows me to consume OSGi services as SCA components. I'm sure >> it's not >> perfect, but it's a start. :-) > > Sounds like a pretty good start :-) > >> I've also got some OSGi-specific implementations of some of the >> boot-strappy classes for dealing with classloader issues and some >> manager code that allows sca applications (packaged as bundles) to >> run >> in separate contexts. > > :-) > >> I'd like to provide this code to Tuscany and help complete the >> implementation. How would you like me to proceed? Do you have time to >> look at it and point out where I've gone astray? > > Thank you. If you can create a JIRA and attach what you have as a > patch or zip archive I would suggest we check this in to the trunk > but do not include in the main build just yet. This sounds like a > cool and valuable contribution. Yea that would be great. If you can do that, I'll go in and clean out the old equinox project shell I started a while back. Good to hear from you again too. Jim > > 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] 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]
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 7:46 AM, Jeremy Boynes wrote: On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) Sounds like a pretty good start :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. :-) I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thank you. If you can create a JIRA and attach what you have as a patch or zip archive I would suggest we check this in to the trunk but do not include in the main build just yet. This sounds like a cool and valuable contribution. Yea that would be great. If you can do that, I'll go in and clean out the old equinox project shell I started a while back. Good to hear from you again too. Jim 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]
Re: Inheriting Wiring infrastructure
On Aug 9, 2006, at 7:35 AM, Hawkins, Joel wrote: Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) Sounds like a pretty good start :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. :-) I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thank you. If you can create a JIRA and attach what you have as a patch or zip archive I would suggest we check this in to the trunk but do not include in the main build just yet. This sounds like a cool and valuable contribution. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inheriting Wiring infrastructure
Hello Jims (Venkata, and everyone else struggling with bindings, etc.) I have an OSGi binding implementation that's sort of working now (I can run the SupplyChain example in equinox, repackaged into a couple of bundles, etc). There's a binding.osgi that allows me to expose SCA services as OSGi services, and there's an implementation.osgi that allows me to consume OSGi services as SCA components. I'm sure it's not perfect, but it's a start. :-) I've also got some OSGi-specific implementations of some of the boot-strappy classes for dealing with classloader issues and some manager code that allows sca applications (packaged as bundles) to run in separate contexts. I'd like to provide this code to Tuscany and help complete the implementation. How would you like me to proceed? Do you have time to look at it and point out where I've gone astray? Thanks, Joel Hawkins -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 10:31 PM To: tuscany-dev@ws.apache.org Subject: Re: Inheriting Wiring infrastructure On Aug 8, 2006, at 10:38 AM, Venkata Krishnan wrote: > Hi Jim / Jeremy / Axis2 & Celtix binding folks > > Continuing with the simple RMI Binding that I am working on... here > are the > things that I have done to move it forward in steps... (from a null > inbound > wire to being able to host the RMI Service. Now I am on the path to > invoking the service). Here is what I have done in the > RMIBindingBuilder.build method: - > > - created the inbound and outbound wires > - set up anInbound and Outbound Invocations chain for these wires > resp. > - set up a Java target invoker on the InboundWire (did not > understand this > as I expected that this should be set onto the outbound wire) You should only need to create the target invoker for the reference and not the service side (the target invoker is responsible for dispatching on a service). The invoker itself is cached on the target side and sent down the invocation chain with the message, pulled off by the final interceptor and invoked. This process is described in the slides under /doc. The reason for this is so target invokers can be optimized to avoid resolution on every invoke when the source of a wire is of the same or lesser scope than the target (e.g. request-- >request; request-->module). > - Now I am stuck with Interceptors... it seems like the outbound > wire need > to be configured with interceptor. This seems to be little tricky > as I must > create MessageChannels and so on... any suggestions on how I could > do this? > Yes it's very tricky, particularly with callbacks ;-) The connector handles this so the extension developer should not need to worry. > Axis2 and Celtix folks, how have you guys done this?If this is > not the > way to do this, what else is? > If you give me until tomorrow, I'll check a sample binding in of how to do this. I also have some related changes I want to discuss pertaining to the Wire Service and how wires are produced so I'll post in a related email. Jim - 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]
Re: Inheriting Wiring infrastructure
one clarification below... On Aug 8, 2006, at 7:30 PM, Jim Marino wrote: On Aug 8, 2006, at 10:38 AM, Venkata Krishnan wrote: Hi Jim / Jeremy / Axis2 & Celtix binding folks Continuing with the simple RMI Binding that I am working on... here are the things that I have done to move it forward in steps... (from a null inbound wire to being able to host the RMI Service. Now I am on the path to invoking the service). Here is what I have done in the RMIBindingBuilder.build method: - - created the inbound and outbound wires - set up anInbound and Outbound Invocations chain for these wires resp. - set up a Java target invoker on the InboundWire (did not understand this as I expected that this should be set onto the outbound wire) You should only need to create the target invoker for the reference and not the service side (the target invoker is responsible for dispatching on a service). The invoker itself is cached on the target side Sorry, I should have said the "target invoker is cached on the source side"...mistyped. Jim and sent down the invocation chain with the message, pulled off by the final interceptor and invoked. This process is described in the slides under /doc. The reason for this is so target invokers can be optimized to avoid resolution on every invoke when the source of a wire is of the same or lesser scope than the target (e.g. request-->request; request-->module). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inheriting Wiring infrastructure
On Aug 8, 2006, at 10:38 AM, Venkata Krishnan wrote: Hi Jim / Jeremy / Axis2 & Celtix binding folks Continuing with the simple RMI Binding that I am working on... here are the things that I have done to move it forward in steps... (from a null inbound wire to being able to host the RMI Service. Now I am on the path to invoking the service). Here is what I have done in the RMIBindingBuilder.build method: - - created the inbound and outbound wires - set up anInbound and Outbound Invocations chain for these wires resp. - set up a Java target invoker on the InboundWire (did not understand this as I expected that this should be set onto the outbound wire) You should only need to create the target invoker for the reference and not the service side (the target invoker is responsible for dispatching on a service). The invoker itself is cached on the target side and sent down the invocation chain with the message, pulled off by the final interceptor and invoked. This process is described in the slides under /doc. The reason for this is so target invokers can be optimized to avoid resolution on every invoke when the source of a wire is of the same or lesser scope than the target (e.g. request-- >request; request-->module). - Now I am stuck with Interceptors... it seems like the outbound wire need to be configured with interceptor. This seems to be little tricky as I must create MessageChannels and so on... any suggestions on how I could do this? Yes it's very tricky, particularly with callbacks ;-) The connector handles this so the extension developer should not need to worry. Axis2 and Celtix folks, how have you guys done this?If this is not the way to do this, what else is? If you give me until tomorrow, I'll check a sample binding in of how to do this. I also have some related changes I want to discuss pertaining to the Wire Service and how wires are produced so I'll post in a related email. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
