Shash Chatterjee wrote:
> Made some progress, but still stuck! After much looking at source, I finally
> figured out parts of the puzzle, can somebody please confirm or not that
> this is correct? The selector is specified like this:
>
> In roles.xconf:
> <roles>
> <role name="org.whatever.services.things.thing">
> <component
> shorthand="things"
>
> class="org.apache.excalibur.fortress.lookup.FortressServiceSelector"
>
> handler="org.apache.excalibur.fortress.handler.FactoryComponentHandler"/>
> <component
> shorthand="thing1"
> class="org.whatever.things.thing1"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> <component
> shorthand="thing2"
> class="org.whatever.things.thing2"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> <component
> shorthand="thing3"
> class="org.whatever.things.thing3"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> </role>
> </roles>
>
> And in system.xconf:
> <app>
> <things id="selector">
> <thing1 id="mything1">
> .....
> </thing1>
> <thing2 id="mything2">
> ....
> </thing2>
> </things>
> .....
> </app>
>
> This in principle works, until I have two roles that use the
> FortressServiceSelector. Then it seems to use the shorthand to find the
> class, FortressServiceSelector, and then uses FortressServiceSelector to
> find the role, which of course is the last role in roles.conf that specifies
> FortressServiceSelector. Does this mean that I have to extend
> FortressServiceSelector once for each role just so the selector-to-role
> entry in the map is unique? Please say "it a'int so, you're doing something
> wrong dummy!".
>
> Shash
>
>
> ----- Original Message -----
> From: "Shash Chatterjee" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, October 13, 2002 10:27 AM
> Subject: Fortress config file format
>
>
> Hi all!
>
> I am trying to migrate from an ECM-based container to
> Fortress/DefaultContainer, primarily so I can use the life-cycle extention
> capability. I am a bit confused about the config. formats, particularly
> with selectors. The real question is at the bottom, with a pertinment
> example here:
>
> For example, originally in roles.xconf, we had:
> <roles>
> <role
> name="org.whatever.services.things.thingSelector" <-- with
> "Selector" added to the ROLE name
> shorthand="things"
>
> default-class="org.apache.excalibur.component.DefaultComponentSelector">
> <hint shorthand="thing1", class="org.whatever.things.thing1">
> <hint shorthand="thing2", class="org.whatever.things.thing1">
> <hint shorthand="thing3", class="org.whatever.things.thing1">
> </role>
> ,,,,,,
> </roles>
>
> and in system.xconf, we had:
> <app>
> <things>
> <thing1 name="mything1">
> .....
> </thing1>
> <thing2 name="mything2">
> ....
> </thing2>
> </things>
> .....
> </app>
>
> With Fortress/DefaultContainer, I am thinking system.xconf stays the same
> and roles.xconf should become:
>
> <roles>
> <role name="org.whatever.services.things.thing">
> <component
> shorthand="thing1"
> class="org.whatever.things.thing1"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> <component
> shorthand="thing2"
> class="org.whatever.things.thing2"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> <component
> shorthand="thing3"
> class="org.whatever.things.thing3"
>
> handler="org.apache.excalibur.fortress.handler.ThreadSafeComponentHandler"/>
> </role>
> </roles>
>
> So my question is, how/where do I specify the selector and where do I
> specify its shorthand (i.e. the "things" so I can use the
> "<things>...</things>" elements)? Maybe, I should be using "id" as the
> component-shorthand, and "shorthand" as the selector-shorthand? The old
> convention was, if you asked for 'ROLE + "Selector"' you'd get the Selector,
> but asking for "ROLE" would get the component. How is this accomplished
> now?
>
> One other question, a couple of the examples show .xinfo files. Is the
> use/format of that file documented somewhere?
You converted the roles file correctly. Right now the DefaultContainer does not
descend any levels looking for a components living in a selector. That is
because all the components live in the root level.
The choice for a Selector is done automatically when you append the "Selector"
to the lookup name. That way you can have some components that only work with
the default component for the type, and others that select it from a group of
other components.
For now, ignore the xinfo files. That is for the future planned support
for a meta-info enabled container. That container will be more powerful,
but much different from the current container. We don't have a working
version yet, but that will change soon.
If you want to explicitly support the
<things><thing/></things>
construct, you will have to extend DefaultContainer and override the
configure() method.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
