Hi all,
I have been working on the support for accessing / injecting
configurations as Maps. I've implemented it using an additional
"key-attribute" attribute on <element>. As a result the objects
created (and pushed onto the stack) by the <rules> or <conversion>
element will also be made available as keyed entries in a Map.
I was just looking for some good candidates in HiveMind codebase which
could benefit from mapped configurations and realized that this is
even cooler than I first thought :-)
Take the hivemind.ObjectProviders for example. Here we could now
inject the configuration as a Map of ObjectProviderContribution
objects keyed on the prefix String. This in itself wouldn't be very
helpful as the ObjectTranslator service (into which the configuration
is injected) still needs to process every entry in the Map. But when
one realizes that the ObjectProviderContribution class in essence is
what the Map.Entry class already is, the mapped configuration can
really be leveraged: We can live without the
ObjectProviderContribution class and remove the contributions
processing in ObjectTranslator all together. This requires a change
to the schema rules. We replace:
<schema>
<element name="provider">
<attribute name="prefix" required="true"/>
<attribute name="service-id" required="true" translator="service"/>
<conversion
class="org.apache.hivemind.service.impl.ObjectProviderContribution">
<map attribute="service-id" property="provider"/>
</conversion>
</element>
</schema>
with:
<schema>
<element name="provider" key-attribute="prefix">
<attribute name="prefix"/>
<attribute name="service-id" required="true" translator="service"/>
<rules>
<push-attribute attribute="service-id"/>
<invoke-parent method="addElement"/>
</rules>
</element>
</schema>
Note that the schema hasn't really changed, just the way it's being processed.
--knut
On Wed, 17 Nov 2004 13:48:30 +0100, Knut Wannheden
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> This discussion just resurfaced on hivemind-user. So it seems like
> there are others who'd like to see HiveMind have the possibility to
> inject configuration contributions as a Map (in addition to List).
> Also here the idea of adding an additional attribute for this purpose
> came up. I think there are basically two choices:
>
> - <element name="foo" key-attribute="bar">
> - <attribute name="bar" key="true">
>
> I suppose both have advantages and disadvantages, but IMHO the
> attribute on <element> makes more sense. What do others think?
>
> --knut
>
> On Thu, 28 Oct 2004 06:52:05 -0700, Liebig, Stefan
>
>
> <[EMAIL PROTECTED]> wrote:
> >
> > Yes, you are wright, an additional attribute would be much better!
> >
> > And again yes, a more "sophisticated" handling of contributions would
> > also be nice!
> >
> >
> >
> > compeople AG
> > Untermainanlage 8
> > 60329 Frankfurt
> >
> > fon: +49 (69) 272218 - 0
> > fax: +49 (69) 272218 - 22
> > email: [EMAIL PROTECTED]
> > home: www.compeople.de
> >
> > -----Original Message-----
> > From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED]
> > Sent: Thu 28.10.2004 15:22
> > To: [email protected]
> > Subject: RE: Injecting of Configurations/Contributions
> >
> > Hi,
> >
> > This seems a good idea to me (I already had this requirement but finally I
> > could do without after a big redesign).
> > However, I don't think that the choice of the key should be based on the
> > "one attribute that is unique", what if more than one attribute is unique?
> > Probably this should be a new property in the schema definition to indicate
> > this fact.
> >
> > Generally speaking, one common problem with HiveMind configuration currently
> > is that whatever the configuration you always get a List injected (same
> > problem with parameters to factories)
> > This sounds awkward in particular for cases where the configuration (or
> > parameters) define exactly one, or (0 or one) occurrences. In this case,
> > having to call get(0) and cast it to the right Contribution code seems
> > boring when you have done it a few times...
> > Maybe having a better injection of Contributions in that case, that would
> > directly pass the specific Contribution object (or null if no contribution
> > was provided) would be "nice to have".
> >
> > Just my 2c.
> >
> > -----Original Message-----
> > From: Liebig, Stefan [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 28, 2004 3:36 PM
> > To: [email protected]
> > Subject: Injecting of Configurations/Contributions
> >
> > I have very often the case that I have to convert the List of contributions
> > into a Map for faster access. In such cases I have always marked a single
> > attribute with unique="true". This attribute will get the key of my Map. The
> > values will the corresponding contribution elements or their mapping class.
> >
> > I would like to have constructors of services such as:
> > a) MyServiceOne( Map allContributions )
> >
> > b) MyServiceTwo( List allContributions )
> >
> > for both services their would be a constructor injection such as:
> > <configuration>AllContributions</configuration>
> >
> > In case a) HiveMind should create a Map from �AllContributions� and in b) a
> > List.
> > Creating a Map requieres exactly one attribute/property marked as unique.
> >
> > Do other have similar needs?
> >
> > Stefan Liebig
> > compeople AG
> > Untermainanlage 8
> > 60329 Frankfurt
> >
> > fon: +49 (69) 272218 - 0
> > fax: +49 (69) 272218 - 22
> > email: [EMAIL PROTECTED]
> > home: www.compeople.de
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
