You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Knut Wannheden <kn...@gmail.com> on 2005/05/20 14:53:32 UTC
Re: Using Java code to instantiate services
Achim,
On 5/20/05, Achim Huegen <ah...@gmx-topmail.de> wrote:
> Nevertheless it won't be trivial to do and might force some paradigm shift.
> For example currently the configurations, factory and interceptor parameters
> are lazily parsed. That is, on first access.
>
I agree that it wouldn't be a trivial undertaking. I'd also expect a
change like this to to some extent impact the classes the
RegistryInfrastructureConstructor class is dealing internally with.
The lazy loading is certainly nothing we'd like to give up. I don't
either see how that would be a problem in this API. One thing I'm
wondering about is if also the classloading should be deferred as long
as possible. This would be consistent with the current approach but
would result in a slightly more cryptic API. E.g. a
getServiceInterfaceClassName() instead of a
getServiceInterfaceClass().
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Using Java code to instantiate services
Posted by Knut Wannheden <kn...@gmail.com>.
Achim,
On 5/21/05, Achim Huegen <ah...@gmx-topmail.de> wrote:
>
> >
> > I had something different in mind. Something which much closer
> > resembles what the current API with the *Descriptor classes looks
> > like. Just interfaces instead of classes and with XML specifics
> > stripped of. So for example:
> >
> > public interface Contribution
> > {
> > String getExtensionPointId();
> > Object[] getElements();
> > }
> >
> > There would of course be an "owning" Module interface with a
> > getContributions() method to establish the module relationship.
> >
> > An implementation of this interface would return the
> > SymbolSourceContribution objects with a call to getElements(). The
> > implementation could then chose to implement a lazy loading strategy
> > or not.
> >
> > Does that make sense?
> >
>
> I see what you mean and it does make sense.
> Probably in ContributionDescriptor the getElements method would be replaced with:
>
> public Contribution getContributions()
>
I thought that instead the ContributionDescriptor class should
implement the Contribution interface I described.
>
> What is still bothering me is that it's so much work just to contribute one object
> to a configuration. You have to implement a ModuleDescriptorProvider, that
> returns a ModuleDescriptor, which contains a ContributionDescriptor which finally
> returns the Contribution.
That is exactly what I thought we should try to simplify. I was
thinking of a RegistryBuilder with a simple addModule(Module) method,
where the Module interface looks something like:
public interface Module
{
Set getServicePoints();
Set getImplementations();
Set getInterceptors();
Set getConfigurationPoints();
Set getContributions();
Set getSchemas();
}
It should also be possible to implement a "pull API" like
ModuleDescriptorProvider on top of this.
> The main task of RegistryInfrastructureConstructor is to unroll these hierarchy
> and finally call ConfigurationPoint.addContribution()
> And that's what I would like to call directly. This could be the core API
> that is used by RegistryInfrastructureConstructor. I would even refactor RegistryInfrastructureConstructor and extract all ModuleDescriptor specific parts
> to another class (ModuleDescriptorProcessor?)
>
I'd say the main task of RegistryInfrastructureConstructor is to pull
together all extensions (speak: implementations, interceptors, and
contributions) from the various modules and add them to the respective
extension points. But I agree with you, there is a core API below this
level in which a module only contains extension points, which contain
their extensions. This core API does exist, but IMO it contains some
things which really belong to this "registry construction API" I'm
trying to come up with.
To respect HiveMind's concept of modules (with distributed extensions)
I think the Java API you'd like to see would have to be implemented on
top of this registry construction API. But that should be possible,
no?
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Using Java code to instantiate services
Posted by Achim Huegen <ah...@gmx-topmail.de>.
>
> I had something different in mind. Something which much closer
> resembles what the current API with the *Descriptor classes looks
> like. Just interfaces instead of classes and with XML specifics
> stripped of. So for example:
>
> public interface Contribution
> {
> String getExtensionPointId();
> Object[] getElements();
> }
>
> There would of course be an "owning" Module interface with a
> getContributions() method to establish the module relationship.
>
> An implementation of this interface would return the
> SymbolSourceContribution objects with a call to getElements(). The
> implementation could then chose to implement a lazy loading strategy
> or not.
>
> Does that make sense?
>
I see what you mean and it does make sense.
Probably in ContributionDescriptor the getElements method would be replaced with:
public Contribution getContributions()
What is still bothering me is that it's so much work just to contribute one object
to a configuration. You have to implement a ModuleDescriptorProvider, that
returns a ModuleDescriptor, which contains a ContributionDescriptor which finally
returns the Contribution.
The main task of RegistryInfrastructureConstructor is to unroll these hierarchy
and finally call ConfigurationPoint.addContribution()
And that's what I would like to call directly. This could be the core API
that is used by RegistryInfrastructureConstructor. I would even refactor RegistryInfrastructureConstructor and extract all ModuleDescriptor specific parts
to another class (ModuleDescriptorProcessor?)
Achim
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Using Java code to instantiate services
Posted by Knut Wannheden <kn...@gmail.com>.
On 5/20/05, Achim Huegen <ah...@gmx-topmail.de> wrote:
> I just made a graph of the dependencies on the parse and schema packages.
> Have a look here http://wiki.apache.org/jakarta-hivemind/XMLDependencies
> Maybe this can give you some hints about what other classes has to be changed.
>
Nice.
> I think lazy loading will get difficult, if you plan to work with typed objects.
> Example :
> A contribution to configuration 'symbolsources' could work like this:
>
> SymbolSourceContribution contr = new SymbolSourceContribution();
> contr.setName('newSource');
> ...
> registrybuilder.addContribution('symbolsource', contr);
>
> Do you have something different in mind or how would you implement lazy loading her?
>
I had something different in mind. Something which much closer
resembles what the current API with the *Descriptor classes looks
like. Just interfaces instead of classes and with XML specifics
stripped of. So for example:
public interface Contribution
{
String getExtensionPointId();
Object[] getElements();
}
There would of course be an "owning" Module interface with a
getContributions() method to establish the module relationship.
An implementation of this interface would return the
SymbolSourceContribution objects with a call to getElements(). The
implementation could then chose to implement a lazy loading strategy
or not.
Does that make sense?
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Using Java code to instantiate services
Posted by Achim Huegen <ah...@gmx-topmail.de>.
I just made a graph of the dependencies on the parse and schema packages.
Have a look here http://wiki.apache.org/jakarta-hivemind/XMLDependencies
Maybe this can give you some hints about what other classes has to be changed.
I think lazy loading will get difficult, if you plan to work with typed objects.
Example :
A contribution to configuration 'symbolsources' could work like this:
SymbolSourceContribution contr = new SymbolSourceContribution();
contr.setName('newSource');
...
registrybuilder.addContribution('symbolsource', contr);
Do you have something different in mind or how would you implement lazy loading her?
Achim
Am Fri, 20 May 2005 14:53:32 +0200 schrieb Knut Wannheden <kn...@gmail.com>:
> Achim,
>
> On 5/20/05, Achim Huegen <ah...@gmx-topmail.de> wrote:
>> Nevertheless it won't be trivial to do and might force some paradigm shift.
>> For example currently the configurations, factory and interceptor parameters
>> are lazily parsed. That is, on first access.
>>
>
> I agree that it wouldn't be a trivial undertaking. I'd also expect a
> change like this to to some extent impact the classes the
> RegistryInfrastructureConstructor class is dealing internally with.
>
> The lazy loading is certainly nothing we'd like to give up. I don't
> either see how that would be a problem in this API. One thing I'm
> wondering about is if also the classloading should be deferred as long
> as possible. This would be consistent with the current approach but
> would result in a slightly more cryptic API. E.g. a
> getServiceInterfaceClassName() instead of a
> getServiceInterfaceClass().
>
> --knut
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org