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 <[EMAIL PROTECTED]>:
Achim,
On 5/20/05, Achim Huegen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
