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
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
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
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
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
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
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
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,
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
