You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Vandahl <tv...@apache.org> on 2007/08/18 15:59:58 UTC
TorqueSecurityService fails tests/NPE in BasePeer
Hi folks,
I'm in the process of making Turbine 2.3.3 "Torque 3.3" safe. (Torque
folks, please read on!) This involved changing DBSecurityService to
extend TorqueSecrityService and fixing the OM-classes in the Turbine
code base. I will comment on this separately.
Now after doing this, the TurbineSecurity tests failed on me. So I
thought I broke this. But further debugging showed that I get a
NullPointerException in BasePeer.doSelect() because the database adapter
of the "default" database is null (This has always been the case!).
This is a standard operation that happens with every doSelect() call and
would have been surfaced long ago, so I'm puzzled why this happens here.
Obviously some mapping from the "default" database reference to the real
database object is missing. The only difference of the call in
TorqueSecurityService is that the Peer class methods are being called by
introspection.
I managed to fix it by adding the DBAdapter in addition to the
DataSourceFactory of the default database to the "reference database". I
suspect, however, that this only cured a symptom, not the real cause.
Any help on this is appreciated.
Still puzzled,
Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: TorqueSecurityService fails tests/NPE in BasePeer
Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Fischer wrote:
> I'm not sure if I understand the turbine initialisation process of
> Torque correctly. I assume the following (correct me if I'm wrong):
>
> 1) Torque.init(...) is called before a select is attempted.
Yep.
> 2) In the configuration provided to Torque.init(), the key
> "torque.database.default" is set to the value "default"
No. The relevant part of the configuration is like this:
---8<---
torque.database.default = test
torque.database.test.adapter = hypersonic
torque.dsfactory.test.factory = \
org.apache.torque.dsfactory.SharedPoolDataSourceFactory
torque.dsfactory.test.connection.driver = org.hsqldb.jdbcDriver
torque.dsfactory.test.connection.url = jdbc:hsqldb:.
torque.dsfactory.test.connection.user = sa
torque.dsfactory.test.connection.password =
---8<---
Everything looks quite normal to me.
> If this is the case, in TorqueInstance.java line 314ff it is ensured
> that the database "default" is not null.
>
> Maybe this is relevant: I remember dimly that there was some mad logic
> with the word "default" when the default database was not set, which was
> used by turbine. I removed this logic during clean-up of the torque
> initialisation process back in 2005. I'd guess this is the relevant
> commit message:
> http://mail-archives.apache.org/mod_mbox/db-torque-dev/200507.mbox/%3C20050708175334.64249.qmail@minotaur.apache.org%3E
>
The important line is in BasePeer.doSelect(criteria, con)
DB dbadapter = Torque.getDB(criteria.getDbName());
Here, the database name in criteria is "default", which points to the
reference to "test". Because during the setup, only the
DataSourceFactory is copied to the reference, in the reference Database
object the adapter is null. In the next lines of BasePeer
// Call Village depending on the capabilities of the DB
return executeQuery(query.toString(),
dbadapter.supportsNativeOffset() ? 0 :
criteria.getOffset(),
dbadapter.supportsNativeLimit() ? -1 :
criteria.getLimit(),
criteria.isSingleRecord(),
con);
this must lead to a NullPonterException.
Now the question is: Why doesn't this happen all the time? I remember
some strange mapping code which replaces the "default" in Criteria with
the actual name of the default database but I can't find it anymore.
Should I simply commit that change to TorqueInstance (adding the adapter
to the reference as well?)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: TorqueSecurityService fails tests/NPE in BasePeer
Posted by Thomas Vandahl <tv...@apache.org>.
Thomas Fischer wrote:
> I'm not sure if I understand the turbine initialisation process of
> Torque correctly. I assume the following (correct me if I'm wrong):
>
> 1) Torque.init(...) is called before a select is attempted.
Yep.
> 2) In the configuration provided to Torque.init(), the key
> "torque.database.default" is set to the value "default"
No. The relevant part of the configuration is like this:
---8<---
torque.database.default = test
torque.database.test.adapter = hypersonic
torque.dsfactory.test.factory = \
org.apache.torque.dsfactory.SharedPoolDataSourceFactory
torque.dsfactory.test.connection.driver = org.hsqldb.jdbcDriver
torque.dsfactory.test.connection.url = jdbc:hsqldb:.
torque.dsfactory.test.connection.user = sa
torque.dsfactory.test.connection.password =
---8<---
Everything looks quite normal to me.
> If this is the case, in TorqueInstance.java line 314ff it is ensured
> that the database "default" is not null.
>
> Maybe this is relevant: I remember dimly that there was some mad logic
> with the word "default" when the default database was not set, which was
> used by turbine. I removed this logic during clean-up of the torque
> initialisation process back in 2005. I'd guess this is the relevant
> commit message:
> http://mail-archives.apache.org/mod_mbox/db-torque-dev/200507.mbox/%3C20050708175334.64249.qmail@minotaur.apache.org%3E
>
The important line is in BasePeer.doSelect(criteria, con)
DB dbadapter = Torque.getDB(criteria.getDbName());
Here, the database name in criteria is "default", which points to the
reference to "test". Because during the setup, only the
DataSourceFactory is copied to the reference, in the reference Database
object the adapter is null. In the next lines of BasePeer
// Call Village depending on the capabilities of the DB
return executeQuery(query.toString(),
dbadapter.supportsNativeOffset() ? 0 :
criteria.getOffset(),
dbadapter.supportsNativeLimit() ? -1 :
criteria.getLimit(),
criteria.isSingleRecord(),
con);
this must lead to a NullPonterException.
Now the question is: Why doesn't this happen all the time? I remember
some strange mapping code which replaces the "default" in Criteria with
the actual name of the default database but I can't find it anymore.
Should I simply commit that change to TorqueInstance (adding the adapter
to the reference as well?)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: TorqueSecurityService fails tests/NPE in BasePeer
Posted by Thomas Fischer <tf...@apache.org>.
I'm not sure if I understand the turbine initialisation process of Torque
correctly. I assume the following (correct me if I'm wrong):
1) Torque.init(...) is called before a select is attempted.
2) In the configuration provided to Torque.init(), the key
"torque.database.default" is set to the value "default"
If this is the case, in TorqueInstance.java line 314ff it is ensured that
the database "default" is not null.
Maybe this is relevant: I remember dimly that there was some mad logic
with the word "default" when the default database was not set, which was
used by turbine. I removed this logic during clean-up of
the torque initialisation process back in 2005. I'd guess this is the
relevant commit message:
http://mail-archives.apache.org/mod_mbox/db-torque-dev/200507.mbox/%3C20050708175334.64249.qmail@minotaur.apache.org%3E
Regards,
Thomas
On Sat, 18 Aug 2007, Thomas Vandahl wrote:
> Hi folks,
>
> I'm in the process of making Turbine 2.3.3 "Torque 3.3" safe. (Torque
> folks, please read on!) This involved changing DBSecurityService to
> extend TorqueSecrityService and fixing the OM-classes in the Turbine
> code base. I will comment on this separately.
>
> Now after doing this, the TurbineSecurity tests failed on me. So I
> thought I broke this. But further debugging showed that I get a
> NullPointerException in BasePeer.doSelect() because the database adapter
> of the "default" database is null (This has always been the case!).
>
> This is a standard operation that happens with every doSelect() call and
> would have been surfaced long ago, so I'm puzzled why this happens here.
> Obviously some mapping from the "default" database reference to the real
> database object is missing. The only difference of the call in
> TorqueSecurityService is that the Peer class methods are being called by
> introspection.
>
> I managed to fix it by adding the DBAdapter in addition to the
> DataSourceFactory of the default database to the "reference database". I
> suspect, however, that this only cured a symptom, not the real cause.
> Any help on this is appreciated.
>
> Still puzzled,
> Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: TorqueSecurityService fails tests/NPE in BasePeer
Posted by Thomas Fischer <tf...@apache.org>.
I'm not sure if I understand the turbine initialisation process of Torque
correctly. I assume the following (correct me if I'm wrong):
1) Torque.init(...) is called before a select is attempted.
2) In the configuration provided to Torque.init(), the key
"torque.database.default" is set to the value "default"
If this is the case, in TorqueInstance.java line 314ff it is ensured that
the database "default" is not null.
Maybe this is relevant: I remember dimly that there was some mad logic
with the word "default" when the default database was not set, which was
used by turbine. I removed this logic during clean-up of
the torque initialisation process back in 2005. I'd guess this is the
relevant commit message:
http://mail-archives.apache.org/mod_mbox/db-torque-dev/200507.mbox/%3C20050708175334.64249.qmail@minotaur.apache.org%3E
Regards,
Thomas
On Sat, 18 Aug 2007, Thomas Vandahl wrote:
> Hi folks,
>
> I'm in the process of making Turbine 2.3.3 "Torque 3.3" safe. (Torque
> folks, please read on!) This involved changing DBSecurityService to
> extend TorqueSecrityService and fixing the OM-classes in the Turbine
> code base. I will comment on this separately.
>
> Now after doing this, the TurbineSecurity tests failed on me. So I
> thought I broke this. But further debugging showed that I get a
> NullPointerException in BasePeer.doSelect() because the database adapter
> of the "default" database is null (This has always been the case!).
>
> This is a standard operation that happens with every doSelect() call and
> would have been surfaced long ago, so I'm puzzled why this happens here.
> Obviously some mapping from the "default" database reference to the real
> database object is missing. The only difference of the call in
> TorqueSecurityService is that the Peer class methods are being called by
> introspection.
>
> I managed to fix it by adding the DBAdapter in addition to the
> DataSourceFactory of the default database to the "reference database". I
> suspect, however, that this only cured a symptom, not the real cause.
> Any help on this is appreciated.
>
> Still puzzled,
> Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org