hivemind-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Huegen <>
Subject Re: Provide runtime symbol source
Date Fri, 04 Mar 2005 08:14:29 GMT
Knut Wannheden wrote:
> You say the symbol values are not known at compile time. You also
> cannot write a SymbolSource service which can access and provide the
> required symbol values at runtime?

That would mean, that the SymbolSource has to parse the web.xml.
But it wouldn't even know where to find it and what to look for without 
some portion of runtime information.

> You are correct about the ModuleDescriptors. They are the only way to
> specify the constituents of the Registry and are intentionally left
> "dumb" as much of the logic requires to have access to all
> ModuleDescriptors. Currently it's not either possible to modify a
> Registry once it's been created, and I don't think this ever will be
> possible.

I hoped there would be an easy way to inject information in the
registry building process. It can be done the way I tried to but
this means fiddling with element and attribute instances.


> --knut
> On Thu, 03 Mar 2005 22:18:25 +0100, Achim Hügen <> wrote:
>>This is not possible, because the symbol values are not known at compile
>>They depend on settings in the web.xml descriptor that are set
>>during deployment.
>>Am Thu, 3 Mar 2005 17:24:12 +0100 schrieb Knut Wannheden
>>>I'm not quite sure I understand your problem, but can't you simply
>>>implement your own SymbolSource as a HiveMind service and have that
>>>contribute the symbols you want?
>>>On Thu, 03 Mar 2005 13:31:56 +0100, Achim Huegen
>>><> wrote:
>>>>I have some problems while trying to provide the init-params of the
>>>>HivemindFilter servlet as symbols to the hivemind registry.
>>>>I don't want to use SystemPropertiesSymbolSource.
>>>>My plan was to add a custom implementation of ModuleDescriptorProvider
>>>>and add an instance to RegistryBuilder via addModuleDescriptorProvider.
>>>>That provider should return a custom implementation of ModuleDescriptor,
>>>>which finally returns a contribution to ApplicationDefaults in
>>>>Then I learned that all the descriptor classes (ContributionDescriptor,
>>>>ImplementationDescriptor) are quite xml centric. I (naively) hoped to be
>>>>able to use instances of FactoryDefault or SymbolSourceContribution
>>>>directly. But the descriptors work with hierarchic elements and
>>>>attributes, the data is in a rather "raw" and untyped format.
>>>>So, is there a way to provide already constructed
>>>>instances/services/contributions to the RegistryBuilder?
>>>>Is there another way to solve this problem without ModuleDescriptors?
>>>>Achim Huegen
>>>>To unsubscribe, e-mail:
>>>>For additional commands, e-mail:
>>>To unsubscribe, e-mail:
>>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message