Alex Karasulu wrote:
<snip/>
Which implies that the ProxyContext class needs to move to the loader
package.
(i.e. part of the low-level bootstrap).
[Karasulu, Alex]
The ProxyContext seems to fit well where you put it within the repository
package. Correct me if I'm wrong but don't we need everything within the
repository spi and impl to be available during kernel bootstrapping on the
system classpath?
OK - this is written after reading the entire email. What you describe below
is basically what is happening under the cli bootstrap approach. The main
jar contains the repository classes and you basically build the system using
the repository to resolve the jar files to build the kernel classloader.
However - this approach means that the repository implementation is accessible
to any component. What I'm assuming is that we can bootstrap simply by knowning
the location of the repository group within ${merlin.home}. From that we can
create a transient classloader containing the repository - and use it simply to
resolve the urls for the kernel classloader. Once we have the kernel up and
running we don't need the transient classloader. End result - components cannot
access the repository.
Anyway - this may emplain why in my head ProxyContext would have to move to the
loader package (because KernelConfig would expose it) and if the repository
package isn't in the system loader - it won't work.
More in-line.
Kernel bootstrapping, as I understand it from the past few emails, needs to do the following:
(listed so you can correct me where I stray)
OK
1). Discover kernel configuration parameters within various sources in the environment (based on defaulting policy).
2). A small subset of the configuration information is used to establish the
system repository to be able to access or snarf down the required artifacts
for creating and populating a ClassLoader used to start the Merlin kernel.
I see the above as a two step process. (a) bootstrap the repository, using MERLIN_HOME (b) bootstrap the kernel using the repository
3). All this happens within the system ClassLoader. The kernel is then started in its own ClassLoader. Now this means we need the classes within the repository packages within the system classpath as well as the loader classes: all preferably within one tight jar. Other jars are added to the kernel ClassLoader as we pull them down or find them in the system repo.
Let me know if I'm on track here.
Yep - your on track.
I think the utility classes like ExceptionHelper, StringHelper, and
property passing can all be pushed into the loader package.
[Karasulu, Alex]
We need to have access to a bunch of classes and interfaces to bootstrap the kernel and these classes must reside within a single kernel bootstrap jar as mentioned above. These bootstrap classes (Loaders, Env variable access utilities and helper classes etc) must be present to establish the system repository. However they need to reside in their appropriate packages. With the classes in the bootstrap jar there is no reason to have duplicates within their respective subproject jars today.
Yep. Things like the exception helper class is duplicated in a least three locations.
So I guess we are going to have the following jar used for virtually every Merlin scenario:
merlin-bootstrap.jar
+1
This jar must contain most of the repository classes and interfaces I would
imagine along with the KernelConfig and Env classes.
I don't think we need to include the repository classes (we can boostrap them in) - it would be simpler in the short term if we did include them - but generally speaking I don't want repository classes exposed.
The jar would need to be on the system classpath. The other api, spi, impl jars for extention, composition, activation would be loaded later from the system repo.
Yep.
Now do the classes loaded from the system repo and the kernel go into their own classloader? Should this be the case always including in the unit testing to avoid the problem you clarified with maven?
Yes and yes.
I'm beginning to think the loader and bootstrap stuff are closely related. I'm just thinking out load here. Shouldn't we keep these in the same project or do we want to separate it? Perhaps this is another example of semantics. Is Merlin, the CLI program, one project and the kernel bootstrapping (loading) code another? If so let's find some names to distinguish between the two and clarify their roles because their names are confusing me and would probably confuse other unfamiliar developers.
I agree.
Currently merlin-boostrap is the CLI handler under kernel/bootstap. We should migrate this to kernel/cli.
Then - kernel/bootstrap is available to be the the real boostrap package. Although this may cause some short term conflicts - I would rather get this right before going final.
I would also like to leverage property parsing when dealing with values in block and kernel descriptors.
[Karasulu, Alex]
Do you mean implementing a form of macro expansion within the XML files similar to the way Ant scripts work with properties?
Yep.
Stephen.
Alex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
