Re: Getting rid of AtomicComponent
On Mar 7, 2007, at 9:57 PM, Meeraj Kunnumpurath wrote: A related question I had was, wouldn't most of the logic in JavaComponent etc for handling properties, introspection etc go into the generated instance factory bytecode? I believe so. I just stubbed out the methods from AtomicComponent for now. When we do the cut-over we can remove them. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting rid of AtomicComponent
A related question I had was, wouldn't most of the logic in JavaComponent etc for handling properties, introspection etc go into the generated instance factory bytecode? Meeraj >> -Original Message- >> From: Jeremy Boynes [mailto:[EMAIL PROTECTED] >> Sent: 08 March 2007 04:08 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Getting rid of AtomicComponent >> >> On Mar 7, 2007, at 6:42 PM, Jim Marino wrote: >> >> > When we convert over to the federated marhsallers, I think >> we can get >> > rid of AtomicComponent and just have Component. To do >> this, we would >> > need to move some of the lifecycle getters such as conversational >> > lifetime, etc. to Component. The other change we would >> need to do is >> > have InstanceWrapper handle init() and destroy >> > () callbacks. I think we can do this by having the wrapper >> generated >> > on the controller and serialized across. This would allow us to >> > eliminate reflection. Finally, JavaTargetInvoker (should be >> > renamed) would then deal with InstanceWrappers which it >> obtained from >> > the ScopeContainer, as opposed to AtomicComponent. >> > >> > What do people think? >> >> I started down that route a while ago refactoring >> InstanceWrapperImpl to be one specialization of >> InstanceWrapperBase that used the current mechanism of >> delegating back to the component (at least until we could >> clean that up). >> >> Have a look at PhysicalComponentTestCase for an example of >> what a generated alternative would look like. >> -- >> Jeremy >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> This message has been checked for all email viruses by MessageLabs * 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: Getting rid of AtomicComponent
On Mar 7, 2007, at 6:42 PM, Jim Marino wrote: When we convert over to the federated marhsallers, I think we can get rid of AtomicComponent and just have Component. To do this, we would need to move some of the lifecycle getters such as conversational lifetime, etc. to Component. The other change we would need to do is have InstanceWrapper handle init() and destroy () callbacks. I think we can do this by having the wrapper generated on the controller and serialized across. This would allow us to eliminate reflection. Finally, JavaTargetInvoker (should be renamed) would then deal with InstanceWrappers which it obtained from the ScopeContainer, as opposed to AtomicComponent. What do people think? I started down that route a while ago refactoring InstanceWrapperImpl to be one specialization of InstanceWrapperBase that used the current mechanism of delegating back to the component (at least until we could clean that up). Have a look at PhysicalComponentTestCase for an example of what a generated alternative would look like. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Getting rid of AtomicComponent
When we convert over to the federated marhsallers, I think we can get rid of AtomicComponent and just have Component. To do this, we would need to move some of the lifecycle getters such as conversational lifetime, etc. to Component. The other change we would need to do is have InstanceWrapper handle init() and destroy() callbacks. I think we can do this by having the wrapper generated on the controller and serialized across. This would allow us to eliminate reflection. Finally, JavaTargetInvoker (should be renamed) would then deal with InstanceWrappers which it obtained from the ScopeContainer, as opposed to AtomicComponent. What do people think? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
