Next: Signalling launch success Up: The launch process in Previous: The launch descriptor in Contents
When the console launches an application it creates a netlet descriptor which it runs on the specified hosting service. The JARs it needs for this netlet are either embedded into that descriptor or, if a SAS warrant has been given (using the sas command above), uploaded to the SAS and referenced from the netlet descriptor. The JARs certainly cannot simply be read from the local file system where they initially reside since the hosting service on the remote node doesn't have access to this.
Of course, every netlet descriptor also carries a signed parameter bean (delivered as the second argument of the initialise() method of INetlet). For this, the launcher creates an ApplicationBean object, which is simply a carrier for all the information from the launch descriptor XML, and loads it up with all the information in the XML. The ApplicationBean is defined in org.jtrix.facets1.util.launcher. The newly-launched netlet can then cast its received parameter bean back into an ApplicationBean, pull out the relevant data, and cold-start to spread itself out. This is why we can define more than one codebase: the newly-launched netlet may want to deploy several kinds of netlet, each with its own codebase.
Actually, the information from the ApplicationBean will necessarily have changed between its original XML (example above) and being delivered to the netlet. First, the JAR locations will have changed. In the example above the launcher reads them from local files which are referenced in the XML. But recall the launch process will upload the JARs to the SAS or embed them in the netlet descriptor; the ApplicationBean references these new JAR locations. Second, the hosting warrant and SAS warrant (if any) given on the console command line are put in the ApplicationBean, so the newly-launched netlet can access these, too. Finally, the cmdline data is replaced by the actual Property values given on the command line and/or their defaults.
All this data, not forgetting the arbitary config data, should be enough to enable the newly-launched netlet to distribute itself as an entire application.