I found my own answer
I was initially thrown by the fact that DSpaceBeanPostProcessor
is not defined anywhere in the source, neither DSpaceConfigurationService
nor BTEBatchImportService
- so I was at a loss what to clue in on.
Once I could boil it
down to a config problem by running the same code with one install
dir and see it fail, but see it succeed with another installation
directory, I read beyond the class not found complaint.
The error talks about /dspace/config/spring/api/bte.xml
which existed in one install directory and not the other.
Removing this and other files under config/spring did the
trick
Now - here my questions:
1) given that we have no local spring related changes in
our DSPACE source and we are doing JSPUI, I assume that I
can safely remove all files under config/spring except for
the ones that come with the default 1.8 release. Correct ?
2) how should I approach house cleaning on our production
config dir, which was not maintained under version control
for a quite some time and probably has all sorts of gunk
in it - does the following look like a safe approach -
will I miss files that I do want by simply listing what is
in config under the source tree ?
git co remotes/upstream/dspace-1_8_x
cd dspace/config/
find . -type f > FILES_I_WANT
cd install_dir/config
find
. -type f > FILES_I_HAVE
and the go over the diff of the two
Monika