Re: [Re: Merlin Queries]

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

Thanks for the answer! Hope you had a good sleep.
Stephen McConnell <mc...@apache.org> wrote:
> 
> 
> Shekhar Jha wrote:
> 
<Snip>
> >
> >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.
---
So the library tag is more for substituting the -Djava.extensions(NOT SURE) at
the command prompt ( for the Kernel and everything managed by it i.e.
containers.

> 
> 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.
-----
I am NOT sure whether this solves the problem that I am describing. Consider
that there is a component/service that needs SSL library for setting up the
connection. Let us assume sombody ships a container with a a very good SSL
library but it does not have license to provide that to the clients. How does
somebody stop the child container and its components have access to those
classes. This is reason for a requirement to specify a container level
CLASSPATH NOT available to its child.

<snipped>

> >
> >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.
-------
Did you have any practical case in mind. Because as I understand the stage and
extension handler are closely connected to each other and very specific the
application that is using it. And the application/service/component MUST
specify how it should be handled. for example, Consider a component that
supports two interface 
Secured which generates a token and Persistable which uses this token to
authorize access to the database to load data. The Handler would be specific
to this application since it requires to call first Secured and then the
Persistable. It can not depend on a default handler to take care of that. 

> 
> >
> >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.
> 
-----
Let us assume that there is a third party component that has private signer
key embedded in its xprofile ( or would you recommend that it be placed at
some other place) which If I understand correctly may be passed to the
component as part of the parameter phase. Now what happens if the assembler
over rides this information with its own private key so that hosting container
passes that information to initialize component resulting in invalid
authorization. I am not sure whether such thing is possible in Merlin ( Have
not completed the code walk through). If it is then May be we MAY want to give
component developer some additional facility to enforce that some parameters
can not be over written by the assembler.



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