Inner composite patch, was Re: Optiional Autowire
Hi Jim, Would you please let me know when you are done applying the inner composite patch? Don't mean to rush you, but I'd rather wait until that is done before I do another update, I imagine my current local sandbox would get pretty messy if I update now ... ;-) I am getting a good picture of what needs to be done for async callbacks over ws binding w/axis2 and I can keep looking at this in my current sandbox until you are done, so it's not like I am stuck. Thanks - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, August 31, 2006 1:38 AM Subject: Re: Optiional Autowire Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inner composite patch, was Re: Optiional Autowire
On 8/31/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: snip/ I am getting a good picture of what needs to be done for async callbacks over ws binding w/axis2 and I can keep looking at this in my current sandbox until you are done, so it's not like I am stuck. Could you post an email about what and how you're looking at doing async and Axis2? There's a few of us who've worked on this binding in the past who'd be interested, I didn't even know you were looking at this until it was mentioned on IRC yesterday (unless I missed some previous email). ...ant
Re: Optiional Autowire
Sure I can give it a shot. I just don't want to interfere with your update. Jim Marino wrote: Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Optiional Autowire
For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked(SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
Yes. System outbound autowire needs to be configured to either throw or not throw an exception based on the resolution strategy. Since I am in the midst of the service contract and operation changes, can you let me make this change after my commit tonight so as not to cause conflicts? Jim On Aug 30, 2006, at 1:17 PM, Rick wrote: For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked (SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - 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: Optiional Autowire
Sure why meddle with the master! :-) Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. Jim Marino wrote: Yes. System outbound autowire needs to be configured to either throw or not throw an exception based on the resolution strategy. Since I am in the midst of the service contract and operation changes, can you let me make this change after my commit tonight so as not to cause conflicts? Jim On Aug 30, 2006, at 1:17 PM, Rick wrote: For webservices binding in the J2SE client case there is an autowire for ServletHost being called, but the jars for this deployment do not include an implementation for this so you receive the following org.apache.tuscany.spi.component.TargetNotFoundException: Autowire target not found [org.apache.tuscany.spi.host.ServletHost] Some discussion on the IRC seems to lead that that the preferred solution is required/optional option on the autowire annotation. I've looked into this and seen where to add it to (ReferenceDefinition) , but where the exception is invoked(SystemOutboundAutowire) I have not been able to pick up where that is passed along. Is this where we could just not throw this exception to have the autowired just ignored? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optiional Autowire
Rick, I realized I need to take a look at Ignacio's patch since I'm sure it won't apply cleanly with the SPI changes in place. So, if you don't mind, could you take a look at adding optional autowires? Here is what needs to be done: 1. Change the autowire annotation to default to required true (obvious) 2. The implementation processing framework needs to be updated to introspect autowire annotations and update ReferenceDefinition.setRequired(). ReferenceDefinition is used to represent references in general, and autowires in particular, which are treated as a type. There are several processors which may need updating. One is ImplementationProcessorServiceImpl. 3. SystemComponentBuilder needs to be modified to deal with ReferenceDefinition.isRequired() for autowires and pass that to the SystemOutboundAutowire constructor (which will need to be modified to add a required field) as it creates system wires. 4. SystemOutboundAutowire when it resolves the autowire will throw an exception if its required field is true. Let me know if I can help out. Jim On Aug 30, 2006, at 2:06 PM, Jim Marino wrote: On Aug 30, 2006, at 1:41 PM, Rick wrote: Sure why meddle with the master! :-) I'd actually not mind avoiding doing it myself but I prefer that to having to reconcile changes Seriously, the only request I would have is if convenient could you make it a separate svn checkin? Just like to review what you did for just this. Yep. That's what I intend to do The autowire information as far as I see is lost in the connection building phase, unless I missed it. Was wondering if it could not be added directly to the ServiceContract. It shouldn't be on the service contract since it is part of the component type (autowire is really a type of reference). ReferenceDefinition already contains the information needed and can be accessed from the system component builder. Jim - 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]
