<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? 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) 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. 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. > 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. So I guess we are going to have the following jar used for virtually every Merlin scenario: merlin-bootstrap.jar This jar must contain most of the repository classes and interfaces I would imagine along with the KernelConfig and Env classes. 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. 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? 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 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? Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
