Re: Repo proxy parameterization within KernelConfigs
Alex Karasulu wrote: 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. [Kara
RE: Repo proxy parameterization within KernelConfigs
> 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]
Re: Repo proxy parameterization within KernelConfigs
Alex Karasulu wrote: I think the devil is definitely in the details. I see why Steve decided to use a Map now. Here's the next issue: Both the system bootstrap repo and the application repo can have proxy settings associated with them and they may not be the same. Fine with me that's just 8 more properties 4 for each repo to parameterize: the host, port, username and password for both system and application repositories. I will add the extra properties. However when accessing these values within the KernelConfig bean I will use an application ProxyContext accessor and a system ProxyContext accessor rather than accessing each property of a ProxyContext individually. Which implies that the ProxyContext class needs to move to the loader package. (i.e. part of the low-level bootstrap). We need to devise defaulting behaviors that take into account property inheritance. To clarify consider the checkbox for setting the shipping address equal to the billing address on websites. We need this kind of defaulting behavior to minimize the property setup overhead. Now with these extra proxy properties I think it is fitting. For example in the absence of application repository properties we can presume the inheritance of system repository property values. We do not have to define the policy in this specific way but it's just an example. +1 The use of macro expansion within the properties file will be a big benefit for things like: merlin.application.repository.proxy.host = ${merlin.system.repository.proxy.host} Thinking the same thing when playing with merlin.properties yesterday. This way defaulting behavior can in many ways be specified within the always present baseline merlin.properties file packaged into the jar. Rather than hard code the logic we can express it via properties using macro expansion. This way some defaulting behavior changes for property values need not require a recompile and maintaining props is much easier. Yep. I think the utility classes like ExceptionHelper, StringHelper, and property passing can all be pushed into the loader package. I would also like to leverage property parsing when dealing with values in block and kernel descriptors. Cheers, Steve. Alex P.S. For those on both lists please forgive the echo onto the LDAP list and the replication it causes - I just want LDAP people to have a record of the things we are doing to further both projects. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repo proxy parameterization within KernelConfigs
I think the devil is definitely in the details. I see why Steve decided to use a Map now. Here's the next issue: Both the system bootstrap repo and the application repo can have proxy settings associated with them and they may not be the same. Fine with me that's just 8 more properties 4 for each repo to parameterize: the host, port, username and password for both system and application repositories. I will add the extra properties. However when accessing these values within the KernelConfig bean I will use an application ProxyContext accessor and a system ProxyContext accessor rather than accessing each property of a ProxyContext individually. We need to devise defaulting behaviors that take into account property inheritance. To clarify consider the checkbox for setting the shipping address equal to the billing address on websites. We need this kind of defaulting behavior to minimize the property setup overhead. Now with these extra proxy properties I think it is fitting. For example in the absence of application repository properties we can presume the inheritance of system repository property values. We do not have to define the policy in this specific way but it's just an example. The use of macro expansion within the properties file will be a big benefit for things like: merlin.application.repository.proxy.host = ${merlin.system.repository.proxy.host} This way defaulting behavior can in many ways be specified within the always present baseline merlin.properties file packaged into the jar. Rather than hard code the logic we can express it via properties using macro expansion. This way some defaulting behavior changes for property values need not require a recompile and maintaining props is much easier. Alex P.S. For those on both lists please forgive the echo onto the LDAP list and the replication it causes - I just want LDAP people to have a record of the things we are doing to further both projects.