Merlin Queries

[Shekhar Jha <sh...@usa.net>]

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.

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?

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?

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?

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.

I am sure there would be good reason for the above. Will help me understand
the product better.
Thanks 
Shekhar



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Merlin Queries

[Stephen McConnell <mc...@apache.org>]

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.

>
>
>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?
>
Its just to seperate common verus Merlin specific keys.
(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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>