Shekhar Jha wrote:
A few queries about merlin.
1. How is the categories known to the the application assembler or kernel.xml writer? It seems he will have to look into each and every Component xinfo file for the logger name. Would that be possible every time. Or is my point of view more of result of flexibility syndrome.
Short answer:
* assembler has too look at the .xinfo * its allway possible but often inconvinient
Longer answer:
The current system will enable third-party enditors to do things like browse containers, inspect types, profiles and component instances, and interactively, update information. The intention is that this will be possible without restarting Merlin. Individual containers can be though of a micro-applications that will be suspendable, restartable, etc. There is more work needed to achieve this but its the direction that we need to go in for things like Cocoon and other business applications.
2. What is difference between library tag and classpath tag? Would it have provided a better facility if the library would have been available to container and its children while classpath would have been specific to the container itself. This may be important in cases for example of usage of different SSL libraries by the container. I think this requirement is met if container classloader CLASSPATH are defined so that the classpath of the child is prefixed to parent classpath. Is that how it is implemented?
On the <library/> tag:
Remember that the <library/> tag is just a collection of directory paths that are used by the classloader to attempt to locate extension jar files. When invoking addURL on a URLClassLoader the URL is scanned firstly for required extensions, and secondly for component types. If an jar extension dependency is found - the system attempts to resolve it using jars located in the library paths. I decided not to make <library/> available at the container level simply on the grounds that it keeps things a little simpler. That could change in the future.
On classloaders and the <classpath/> declaration:
The classloader system in Merlin is hierachical in nature. If you look at the example kernel file for Berlin's project, you will see the declaration of a classpath for the root container in which Conerstone content is defined. Berin's stuff appears in a subsidiary container where we add the supplimentary jar file. Remember that the subsidiary container has access to the classes and components declared in its parent container. Using this approach you can better control the exposure of classes in a system. For example, a container located at the same level as Berin's container cannot access Berin's classes.
Its just to seperate common verus Merlin specific keys.
3. In <context> tag what does merlin: or avalon: stand for? Is it just to distinguish the key types as merlin specific or avalon specific (i.e. name space) or is it some additional processing directive?
(i.e. namespace).
One of the things that people on James have requested in an avalon wide set of common attributes and context keys. For example, in Merlin you have "avalon:home" and the same thing in Phoneix is "app.home". The ideal scanario is that all containers use the same common set of keys where possible. Candidates for common keys are maked as "avalon:someting-or-other" whereas Merlin specific is "merlin:something-else".
4. Why is stage tag needed when it is the LifeCycle handler that needs to know about the interfaces and those interfaces would be implemented by the component?
The <stage/> tag declares a component's depedency on an extension
handler that can handler a particular stage interface. If you look
at the <estension/> tag it declares the interface(s) it can support
(things like Exploitable, Demonstratable, etc.). The stage tag
declares the component's depnedency on a provider of Expliotable,
Demonstratable. When Merlin is assemblying a component it looks for
stage dependencies and then attempts to resolve them by locating the
best extension handler candidate within the type manager hierachy. This approach means that you can easily replace estension handler
implementations indepedently of the components the extension handles.
5. The document says that explicit profile over rides the packaged configuration. But can this feature be used by a package/component user to override security information specified in the package profile. Am I wrong or do we need a "final" directive as a part of the profile definition.
A profile is simply a <component/> declaration packlaged in an .xprofile file. The container handles the assignment of status to profiles as it creates them (actually, its the ContainerManager which is where all of the classpath management and classloading goes on). As such, there isn't a security risk related to a something inside a .xprofile. There is a security risk concerning implementation classes that are introduced - but this is much lower in Merlin than other containers due to the ability to isolate the class in the container hierachy.
I am sure there would be good reason for the above. Will help me understand the product better.
Keep up the questions. But remember that I have a reputation for sometime providing
complicated answers ;-)
Cheers, Steve.
Thanks Shekhar
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
