Albert Zhou wrote:
>Steve,
>
>>From what you described, it appears to me that the
>container manager can be used to load
>components dynamically.
>
Correct.
Take a look at the CustomContainer class - its an example
of a specialization of DefaultContainer and shows how a
component is dynamiocally plugged into the container.
>I believe this is exactly I
>need. That is, the application container
>is passed a .xml file indicating the desired
>implementation of the model/controller/view
>components, and the container is to load these
>components. If any of these is not specified
>in this file, its corresponding default implementation
>is used by the application.
>
Sounds to me like your getting into the area of packaged
profiles - (much simpilar than extending your own container)
see below.
>
>
>I believe the profiles of these components can be
>specified as usual. The question is how
>to specify these profiles in the .xml file to pass to
>the container. Is this feasible under
>the current implementation? Any helpful hints?
>
Yep - packaged profiles.
(see below)
>
>Could you also clarify an explicit profile, a packaged
>profile, and an implicit profile?
>What are they each typically used for? etc. Thanks.
>
In org.apache.excalibur.playground is an example of a
packaged component. If you look at the file
BasicComponet.xprofile what your looking at is the
description of a deployment profile for the component
type BasicComponent.class. This all works in releation
to the notion of explicit, packaged and implicit
profiles:
EXPLIT Profile
A profile extablished as a result of including a
component declaration inside a container declaration
by the assembler (i.e. in something like kernel.xml).
PACKAGED Profile
A profile established by a Merlin container in the
absence of any explicit profiles based on a profile
declaration packaged allong with the component's class
using the <classname>.xprofile resource.
IMPLICIT Profile
In the absence an explicit or packaged profile, Merlin
will attempt to create an implicit profile in order to
satisfy a component dependency. An implicit profile
is in effect Merlin's attempt to put as much together
as it can by looking at the component Class.
In the Merlin demonstration (running the kernel command) you
will see that an instance of SimpleComponent is logging
information within the root container, however - if you look
at the kernel.xml file - there is no <component/> defined
for SimpleComponent at root level. This is an example of
Merlin instantiating an implicit profile. You can spot
implicit and packaged profiles by the logging catagory name
(the have system assigned names e.g. simple-18506989 that are
visible in the log outpout.
Cheers, Steve.
>
>Thanks,
>Albert
>
>--- Stephen McConnell <[EMAIL PROTECTED]> wrote:
>
>>
>>Albert Zhou wrote:
>>
>>
>>>Steve,
>>>
>>>Thanks for your reply. A few more questions for
>>>
>>you.
>>
>>>See below.
>>>
>>>--- Stephen McConnell <[EMAIL PROTECTED]> wrote:
>>>...
>>>
>>>
>>>
>>>>If the eventsystem is a component then you would
>>>>typically declare this
>>>>as a dependency. It is also feasible to supply a
>>>>object via the context
>>>>although this is not recommended practice (using
>>>>
>>the
>>
>>>>context constructor
>>>>arguments in the component profile) -
>>>>
>>>>e.g.:
>>>>
>>>> <context class="MyContextCLass">
>>>>
>>>> <import name="avalon:home" key="base"/>
>>>> <entry key="location" value="Paris"/>
>>>> <entry key="special"
>>>>
>>class="MySpecialClass">
>>
>>>> <parameter>hello</parameter>
>>>> </entry>
>>>> </context>
>>>>
>>>>See also:
>>>>
>>>>
>>>>
>>>>
>>>>
>>http://jakarta.apache.org/avalon/excalibur/merlin/api/
>>
>>>
>>>
>>>
>>>> ... merlin/model/ContextDirective.html
>>>>
>>>>
>>>>
>>>>
>>>1. Who will provide the value of "avalon:home", the
>>>immediate container, or any enclosing one? Any
>>>significance of the characters of ':', '.', etc in
>>>
>>the
>>
>>>key, or it's just for readability?
>>>
>>>
>>The avalon:home is a key to a value provided by the
>>kernel (and therefor
>>the enclosing containers lifecycle manager).
>>The colon is a delimiter between the domain and the
>>property name.
>>
>>
>>>2. In the customer container example
>>>(CustomContainer.xprofile), the context of
>>>key="merlin:container.manager" is imported. It's
>>>defined in the DefaultContainer's .xinfo file. How
>>>
>>are
>>
>>>these two are related? Obviously, I missed
>>>
>>something
>>
>>>here.
>>>
>>>
>>This is Merlin specific key used by a container
>>implememtation to access
>>the ContainerManager (the enhanced classloader).
>>Normally components
>>don't need they can access the classloader by
>>getting
>>Thread.currentThread().getContextClassLoader(),
>>however, during
>>assembly, a container may be executing within the
>>scope of a parent
>>thread and so it may need a direct reference to the
>>classloader it has
>>been assigned. Container iimplementations can use
>>the ContainerManager
>>instance to do things like dynamic componet addition
>>and so on.
>>
>>
>>>3. How to create and pass a complex value (ie, a
>>>user-defined object) in the profile? Possible at
>>>
>>all?
>>
>>>
>>>
>>>
>>1. by creating a component that represents the
>>complex value then
>>declaring a depedency in the target component
>>2. by declaring an address (e.g.
>>corbaloc:iiop:1.2@localhost:2056/planet) in a
>>configuration or
>>parameters - and the component implemetation handles
>>resolution of an
>>object from the reference
>>3. by constructing the object using a context
>>derective (assumming the
>>complex object can be constructed from constructor
>>originated values -
>>as per details in last email)
>>4. privately via some implemetation approach such as
>>accessing a naming
>>service
>>
>>
>>>
>>>
>>>
>>>>>3. How do I configure a non-default component,
>>>>>preferrably outside the
>>>>> startup.xml file?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>You can do this (a) via reference, or (b) via
>>>>packaging:
>>>>
>>>> configuration reference
>>>> -----------------------
>>>>
>>>> <container name=a-container">
>>>> <component name="my-component"
>>>>class="MyComponentClass" >
>>>> <configuration
>>>>
>>>src="../config/bySpecialExternalConfiguration.xml"/>
>>>
>>>> </component>
>>>> </container>
>>>>
>>>>
>>>>
>>>>
>>>1. The "resource://" format works, for which the
>>>
>>.xml
>>
>>>file is stored in one of the .jar files.
>>>
>>>
>>>
>>Yep.
>>
>>
>>>2. What else format of the src attribute and where
>>>
>>the
>>
>>>.xml file located, relative to the defining .xml
>>>
>>file?
>>
>>>
>>>
>>>
>>Regular file names relative to the avalon:home path.
>>This is currrently the root directory in which
>>Merlin is launched.
>>
>>
>>>Steve, what I really was asking was this: is there
>>>
>>a
>>
>>>way to "import" a component defined somewhere else
>>>
>>or
>>
>>>defined later that provides a desired service? For
>>>instance, in my example application, can I import
>>>
>>one
>>
>>>view component in the startup.xml file? Ideally, I
>>>should be able to import a service provider if it's
>>>defined and found somewhere otherwise a default one
>>>will be used.
>>>
>>>
>>>
>>Not yet - but its in progress. I have some content
>>here that is
>>handling the publication however it isn't tied into
>>the assembly
>>mechanisms at this stage. The objective is to
>>enable containers to
>>publish services based on disclosure policies at the
>>level of the
>>component and container. These services will then
>>become candidates for
>>assembly in other contains and compoents. This
>>included the ability to
>>export a service access point description between
>>containers enabling
>>remote assembly, execution and dissasembly across
>>different machines.
>>
>>
>>>
>>>
>>>
>>>> packaged configuration
>>>> ----------------------
>>>>
>>>> Just include the configuration as an
>>>><classname>.xconfig file
>>>> in the same package as the class.
>>>>
>>>>Cheers, Steve.
>>>>
>>>>
>>>>
>=== message truncated ===
>
>
>=====
>Regards,
>Albert
>
>__________________________________________________
>Do you Yahoo!?
>New DSL Internet Access from SBC & Yahoo!
>http://sbc.yahoo.com
>
>--
>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]>
