You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Achim Huegen <ah...@gmx-topmail.de> on 2005/03/03 13:31:56 UTC
Provide runtime symbol source
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
getContributions.
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?
Thanks
Achim Huegen
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Provide runtime symbol source
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
Another idea: Maybe you could try using the Groovy support to at
runtime provide your symbols...
--knut
On Fri, 04 Mar 2005 09:14:29 +0100, Achim Huegen <ah...@gmx-topmail.de> wrote:
> 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.
>
> Achim
>
> >
> > --knut
> >
> > On Thu, 03 Mar 2005 22:18:25 +0100, Achim Hügen <ac...@gmx.de> wrote:
> >
> >>This is not possible, because the symbol values are not known at compile
> >>time.
> >>They depend on settings in the web.xml descriptor that are set
> >>during deployment.
> >>
> >>Achim
> >>
> >>Am Thu, 3 Mar 2005 17:24:12 +0100 schrieb Knut Wannheden
> >><kn...@gmail.com>:
> >>
> >>
> >>>Achim,
> >>>
> >>>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?
> >>>
> >>>--knut
> >>>
> >>>On Thu, 03 Mar 2005 13:31:56 +0100, Achim Huegen
> >>><ah...@gmx-topmail.de> 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
> >>>>getContributions.
> >>>>
> >>>>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?
> >>>>
> >>>>Thanks
> >>>>
> >>>>Achim Huegen
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>>
> >>
> >>
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Provide runtime symbol source
Posted by Achim Huegen <ah...@gmx-topmail.de>.
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.
Achim
>
> --knut
>
> On Thu, 03 Mar 2005 22:18:25 +0100, Achim Hügen <ac...@gmx.de> wrote:
>
>>This is not possible, because the symbol values are not known at compile
>>time.
>>They depend on settings in the web.xml descriptor that are set
>>during deployment.
>>
>>Achim
>>
>>Am Thu, 3 Mar 2005 17:24:12 +0100 schrieb Knut Wannheden
>><kn...@gmail.com>:
>>
>>
>>>Achim,
>>>
>>>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?
>>>
>>>--knut
>>>
>>>On Thu, 03 Mar 2005 13:31:56 +0100, Achim Huegen
>>><ah...@gmx-topmail.de> 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
>>>>getContributions.
>>>>
>>>>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?
>>>>
>>>>Thanks
>>>>
>>>>Achim Huegen
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Provide runtime symbol source
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
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?
--knut
On Thu, 03 Mar 2005 13:31:56 +0100, Achim Huegen <ah...@gmx-topmail.de> 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
> getContributions.
>
> 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?
>
> Thanks
>
> Achim Huegen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org