DatabaseReader can't get datasource

[Kazó Csaba <ka...@freemail.hu>]

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.)

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).

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).)

Csaba


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.

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 :)


[1] http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-databases/cocoon-databases-sample/src/main/resources/META-INF/cocoon/avalon/cocoon-databases-sample.xconf
[2] http://localhost:8888/blocks/cocoon-databases-sample/transform/sql-page
[3] http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g2/g1/g2/681.html
[4] http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-databases/cocoon-databases-impl/src/main/java/org/apache/cocoon/reading/DatabaseReader.java

Re: DatabaseReader can't get datasource

[Carsten Ziegeler <cz...@apache.org>]

Grzegorz Kossakowski schrieb:
> Carsten Ziegeler pisze:
> 
>> We support both ways, eiter using a selector (for compatibility) or
>> using the shortcut.
>> Last time I checked (by the end of last year), both ways worked fine.
> 
> Thanks for confirmation.
> 
> I believe that solution for this problem seems to be simple: naming
> convention, see my comment[1] on COCOON-2106.
> 
Yes, hopefully :)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: DatabaseReader can't get datasource

[Grzegorz Kossakowski <gk...@apache.org>]

Carsten Ziegeler pisze:

> We support both ways, eiter using a selector (for compatibility) or
> using the shortcut.
> Last time I checked (by the end of last year), both ways worked fine.

Thanks for confirmation.

I believe that solution for this problem seems to be simple: naming convention, see my comment[1] on COCOON-2106.

[1] https://issues.apache.org/jira/browse/COCOON-2106#action_12517896

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: DatabaseReader can't get datasource

[Carsten Ziegeler <cz...@apache.org>]

Grzegorz Kossakowski wrote
> 
> 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?
> 
We support both ways, eiter using a selector (for compatibility) or
using the shortcut.
Last time I checked (by the end of last year), both ways worked fine.

Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: DatabaseReader can't get datasource

[Kazó Csaba <ka...@freemail.hu>]

> Kazó, have you actually tried current HEAD of trunk? I believe it should work without any glitches. If not, report issues ASAP.

Interestingly, after updating again, it starts with no problem. Strange, there hasn't been a commit since then, and I always use "clean install" to make sure all is right. (It was some Spring bean configuration exception for some xml in the expression-language-impl module, something about non-writable property; but I guess it's false alarm.)

As to the datasource thing, it is kind of hard to tell, what is the most recent, "preferred" way of getting things done. In DatabaseReader and SQLTransformer, I see this non-working way; in the daisy docs, and also in the modular database actions, I see the selector way. I haven't seen any other way, so my knowledge ends here. (Though as far as I can see, there is supposed to be a new "preferred" way: using Spring instead of Avalon, bypassing the bridge; I don't have a clue how to do that.)

Anyway, I'm going to create an issue for this soon, and see what happens.

Thanks,

Csaba

Re: DatabaseReader can't get datasource

[Grzegorz Kossakowski <gk...@apache.org>]

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/