Re: Eager Init sample r416952
Yes, just got net so am about to check in some major changes to the demonstration. Rather than create the parent etc, it now uses the bootstrapper to create the runtime and deploy the scdl. To keep it simple, I left it as a system component so there is just one step in the bootstrap process. We could expand it further but I think that we'll basically end up duplicating the code that would be in the Launcher. Rick, weren't you looking at that? How is it going? -- Jeremy On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote: Basically the runtime has two hierarchical trees, one for application composites and one for system composites. They are separate but contained by the runtime. The bootstrapper will be responsible for setting all of this up, including default system composites and services so end-users won't need to mess with this. Jeremy's been working on that part I believe on his trip now so hopefully he'll have something to show us soon :-) Jim On Jun 25, 2006, at 5:54 PM, Rick wrote: Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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] - 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: Eager Init sample r416952
Jermey, Would still like to get in touch to understand the classpath issues and not using core classes. Jeremy Boynes wrote: Yes, just got net so am about to check in some major changes to the demonstration. Rather than create the parent etc, it now uses the bootstrapper to create the runtime and deploy the scdl. To keep it simple, I left it as a system component so there is just one step in the bootstrap process. We could expand it further but I think that we'll basically end up duplicating the code that would be in the Launcher. Rick, weren't you looking at that? How is it going? -- Jeremy On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote: Basically the runtime has two hierarchical trees, one for application composites and one for system composites. They are separate but contained by the runtime. The bootstrapper will be responsible for setting all of this up, including default system composites and services so end-users won't need to mess with this. Jeremy's been working on that part I believe on his trip now so hopefully he'll have something to show us soon :-) Jim On Jun 25, 2006, at 5:54 PM, Rick wrote: Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eager Init sample r416952
Hi Rick, Could you explain, it sounds as if there may have been a side conversation at some point where I'm missing context? Jim On Jun 26, 2006, at 5:50 AM, Rick wrote: Jermey, Would still like to get in touch to understand the classpath issues and not using core classes. Jeremy Boynes wrote: Yes, just got net so am about to check in some major changes to the demonstration. Rather than create the parent etc, it now uses the bootstrapper to create the runtime and deploy the scdl. To keep it simple, I left it as a system component so there is just one step in the bootstrap process. We could expand it further but I think that we'll basically end up duplicating the code that would be in the Launcher. Rick, weren't you looking at that? How is it going? -- Jeremy On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote: Basically the runtime has two hierarchical trees, one for application composites and one for system composites. They are separate but contained by the runtime. The bootstrapper will be responsible for setting all of this up, including default system composites and services so end-users won't need to mess with this. Jeremy's been working on that part I believe on his trip now so hopefully he'll have something to show us soon :-) Jim On Jun 25, 2006, at 5:54 PM, Rick wrote: Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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] - 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] - 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: Eager Init sample r416952
Hi Jim, The recent check in of the launcher pom.xml has a comment that no tuscany jars should be referenced. The goal is to have the launcher not corrupt the application code with tuscany runtime. My thinking was the launcher could reference these classes at compile time, but at runtime they should all be loaded from another classloader with a separate path that contained the tuscany jars.. It would create a new application classloader to load the application that had only the application jars in it's path. When launcher was created at runtime it would not have the tuscany jars (other than the launcher itself) in it's path. Would that work? ... Maybe Jeremy has a better way to go about this? Jim Marino wrote: Hi Rick, Could you explain, it sounds as if there may have been a side conversation at some point where I'm missing context? Jim On Jun 26, 2006, at 5:50 AM, Rick wrote: Jermey, Would still like to get in touch to understand the classpath issues and not using core classes. Jeremy Boynes wrote: Yes, just got net so am about to check in some major changes to the demonstration. Rather than create the parent etc, it now uses the bootstrapper to create the runtime and deploy the scdl. To keep it simple, I left it as a system component so there is just one step in the bootstrap process. We could expand it further but I think that we'll basically end up duplicating the code that would be in the Launcher. Rick, weren't you looking at that? How is it going? --Jeremy On 6/26/06, Jim Marino [EMAIL PROTECTED] wrote: Basically the runtime has two hierarchical trees, one for application composites and one for system composites. They are separate but contained by the runtime. The bootstrapper will be responsible for setting all of this up, including default system composites and services so end-users won't need to mess with this. Jeremy's been working on that part I believe on his trip now so hopefully he'll have something to show us soon :-) Jim On Jun 25, 2006, at 5:54 PM, Rick wrote: Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe,
Re: Eager Init sample r416952
On 6/26/06, cr22rc [EMAIL PROTECTED] wrote: Hi Jim, The recent check in of the launcher pom.xml has a comment that no tuscany jars should be referenced. The goal is to have the launcher not corrupt the application code with tuscany runtime. Sorry if it caused confusion, I was in there and thinking about it so decided to add the comment to remind us. My thinking was the launcher could reference these classes at compile time, but at runtime they should all be loaded from another classloader with a separate path that contained the tuscany jars.. It would create a new application classloader to load the application that had only the application jars in it's path. When launcher was created at runtime it would not have the tuscany jars (other than the launcher itself) in it's path. Would that work? ... Maybe Jeremy has a better way to go about this? The problem with a compile-time dependency is that typically all the classes need to be available in the same classloader. For example, if MainLauncher imported something from spi, when the code executed the VM would attempt to load the spi class from the classloader that defined MainLauncher; if it couldn't find it, you would get a NoClassDefFoundError. The only solution I know to avoid this is for the launcher code to reference the runtime via reflection. So things would mostly work as you said above. The launcher would create new classloaders for the runtime and the application code to avoid the classpath contamination. It would then locate the default bootstrapper (say using the JAR service mechanism) and invoke it refectively to boot the runtime. Once the runtime was up, it would then invoke the application, for example, by reflectively invoking the main() method as it does now, or by invoking some well-known service as you had suggested elsewhere. [[ of course this is just the launcher; we still have the option of the application code booting the runtime itself using something like TuscanyRuntime ]] -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eager Init sample r416952
I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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]
Re: Eager Init sample r416952
ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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: Eager Init sample r416952
Just a question on this ... today the code creates a parent CompositeComponentImpl. Would this eventually be replaced by the Tuscany loaded system being the parent that is read in from system SCDL ? Or would these component trees be kept separate? Still trying to see how all the pieces fit, but I have to say this really helps. Jim Marino wrote: ok cool - I'm going to bed ;-) On Jun 25, 2006, at 2:12 PM, Jeremy Boynes wrote: I did a couple of tweaks to this in r417080 to start using the capabilities of the deployer. It's not quite done but I wanted to commit what I had (during a layover in ORD) as I think it will be easier to understand than the bare mechanics in Jim's example. For now I turned it into a system component so that I could use the primordial deployer - that should not have much of an example as the two containers are so close. I will switch this back once we have a default system configuration. Jim, as a heads up I'm going to tweak the composite startup code so that we don't need to leak the scope container to the deployer's client. I hope to get that done on the next leg :-) -- Jeremy On 6/24/06, Jim Marino [EMAIL PROTECTED] wrote: I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eager Init sample r416952
I've add a simple temporary class that to the eagerinit sample - LifecycleDemonstration - that demonstrates component lifecycle management, eager initialization, and destruction. As soon as we get the SCDL loading connected to the builders, this class can go away and we will be able to demo an end-to-end scenario. In the meantime, I thought this would be helpful to show the relationship between atomic components, scope containers, and composites. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
