There are two angles from which I can answer your question - I'm not
sure which one you are getting at, possibly because I don't know enough
background to your question.
The first is that the Impala framework itself requires some setup at
runtime, which is done via Spring beans, although for most users would
be controlled via entries in impala.properties.
The second concerns the dependency injection and proxying support which
sits on top of Impala's class loading and module management
capabilities. Again, that is Spring, but here I have been careful to add
abstractions to make it possible to use a non-Spring-based runtime for
within-module wiring of beans and for interacting with the Impala
service registry. To this extent, Impala is already decoupled from
Spring. I have split off separate 'Spring' packages, although I haven't
gone as far as splitting off separate jars, and don't intend to at this
point. So creating an alternative runtime layer for the within module
application configuration and for exporting/importing services from the
service registry is possible (perhaps using something like Google
Guice). I don't have any concrete plans to do this work though.
Hope this answers your question.
Phil
> --
> You received this message because you are subscribed to the Google Groups "impala-users" group.
> To post to this group, send email to impala...@googlegroups.com.
> To unsubscribe from this group, send email to impala_group...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/impala_group?hl=en.
>