We have three packages in the kernel that I would like eventually to
consider stable:
tuscany-api intended to be used by general end-user application code
tuscany-host-api intended to be used by more sophisticated
applications that want control over the runtime
tuscany-spi intended for use by people who want to extend the server
We've not defined yet what stability means :-)
We're also still in early days (cutting milestones not numbered
releases) so for now it would be wise to assume anything can still
change.
--
Jeremy
On Oct 17, 2006, at 8:31 AM, Peter Cousins wrote:
I was just assuming that some of the APIs called in MainLaunchBooter
might not be "supported" APIs. If the APIs used as shown in
MainLaunchBooter are stable and expected to be used by applications,
then that is great. Thanks...PC
-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 17, 2006 11:21 AM
To: [email protected]
Subject: Re: Bootstrapping using MainLaunchBooter question
A bit of history here :-)
In M1 we required that an application create a TuscanyRuntime before
interacting with any SCA code. We had feedback that this was a
problem for application developers and that they should not need to
do that - they should automatically have an SCA context "as if by
magic." For M2 I changed that to have the launcher that would set up
the runtime automatically before invoking the application. I'd say
this hasn't gone down too well given the number of messages we get
about NPE's when accessing the CurrentCompositeContext - generally
from an IDE environment where people set it up to run their main
rather than the launcher's.
I have tried to keep a fairly simple API that allows applications to
boot the runtime themselves. If you look in MainLauncherBooter all
it's really doing is setting up the classloaders, SCDL locations and
RuntimeInfo before calling TuscanyRuntime.initialize().
All of which is prologue to saying that I think we support what you
want to do by allowing your (more sophisticated) application complete
control over the embedded runtime through the TuscanyRuntime API.
Rather than use the launcher, you would have your application be
invoked from main(), do any pre-initialization work needed, and then
boot the runtime using that API.
Is that a reasonable middle ground?
--
Jeremy
On Oct 17, 2006, at 7:50 AM, Peter Cousins wrote:
Currently the main class main method is executed from the main thread
after the rest of the runtime is initialized. I think the
application
main class needs to be able to supply a method that is invoked before
the runtime is initialized in case it needs to do any pre-
initialization
housekeeping. For example, I have an application that creates a JNDI
context for database configuration, and this context needs to be
available to components that might receive a service invocation
before
the main method is invoked, which would cause the service request to
fail. There are many other potential reasons why an application
needs
to be in control before full bootstrapping.
What do you think of adding support for an application class
providing a
method with this signature:
public static void initialize(String[] args) {
}
And then MainLaunchBooter could check for this optional method and
invoke it before it calls runtime.initialize(); ?
Thanks...PC
---------------------------------------------------------------------
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]
