Kazó Csaba pisze:
Hi,
I think I've stumbled upon a bug in the databases block; it's quite obvious but
I've found no mention of it so far.
The problem is that DatabaseReader and SQLTransformer fail to obtain the
configured datasource. (There might be other components with
this problem, but these are the two I know of). The exception says "Component
with
'org.apache.avalon.excalibur.datasource.DataSourceComponent/personnel' is not
defined in this service manager.
(Key='AvalonServiceManager')".
The result is the same whether I define the data source in the Avalon [1] or
Spring way (defining a bean of class
org.springframework.jdbc.datasource.DriverManagerDataSource; at least I think
it's the Spring way, I've found no info about it yet). (The
SQL transformer sample [2] is also broken, so it's probably not me doing
something wrong.)
Your issue is tightly related to the COCOON-2083. In r553872 I have implemented experimental bridge that allows to use connections defined
in Spring way in Avalon classes. I had no time to adapt samples and test it thoroughly, though.
Now, I've found this nice 'Creating a Reader' page [3] and I've noticed that
the code it lists for obtaining the data source is not the
same as in DatabaseReader.java [4]. Upon modifying the reader in accordance
with the sample in [3] it started to work again (both the
Avalon and Spring way).
Good to hear that, it means that the wrapper works correctly!
I'm attaching my modification as a patch to make it easier to see what I'm
talking about. (I have very little understanding of what's
going on in the code involved; the patch might break things more, as far as I can tell,
despite the fact that "It Works For Me"(tm).)
Actually, your patch replaces usage of "simplified obtaining of ECM component"[5] by more "complicated" one, that involves getting selector
component first and only then, a datasource.
The problem is that I have no idea which one (or both) way we support in Cocoon 2.2. If "simplified" way is supported we need to provide fix
for COCOON-2083 enhancing functionality provided there. Otherwise, your patch is correct.
Carsten, can you comment on this?
P.S. I'm using revision 560710 as the current head won't start because of
cocoon-expression-language-impl; I don't think it matters
though, recent commits seem to be unrelated to the issue.
Kazó, have you actually tried current HEAD of trunk? I believe it should work
without any glitches. If not, report issues ASAP.
I usually try to inform the list if some changes breaks trunk for longer time.
P.P.S. If I should've filed a bug report through JIRA, please tell me, and I'll
learn how to do so for the next time :)
Despite your patch is valid or not you should create new issue and attach a patch. It's just easier for us to track things and the chance
that the problem is not overlooked is high, then.
[5] http://article.gmane.org/gmane.text.xml.cocoon.devel/22364
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
