message XSDB8 and 42Y32 have references to db2j
-----------------------------------------------
Key: DERBY-2156
URL: http://issues.apache.org/jira/browse/DERBY-2156
Project: Derby
Issue Type: Bug
Affects Versions: 10.2.1.6, 10.1.3.1
Reporter: Myrna van Lunteren
Priority: Trivial
trunk/messages.xml shows two messages that incorrectly refer to db2j:
42Y32=Aggregator class ''{0}'' for aggregate ''{1}'' on type {2} does not
implement com.ibm.db2j.aggregates.Aggregator.
There is now no class Aggregator in Derby. This message is generated from the
class:
org.apache.derby.impl.sql.compile.AggregateNode.java.
private void checkAggregatorClassName(String className) throws
StandardException
{
className = verifyClassExist(className, false);
if (!classInspector.assignableTo(className,
"org.apache.derby.iapi.sql.execute.ExecAggregator"))
{
throw StandardException.newException
(SQLState.LANG_BAD_AGGREGATOR_CLASS2,
className,
aggregateName,
operand.getTypeId().getSQLTypeName());
}
}
The original in Cloudscape had a reference to an Aggregator class, the if
looked like this:
if (!classInspector.assignableTo(className,
"com.ibm.db2j.aggregates.Aggregator") &&
!classInspector.assignableTo
(className,
"com.ibm.db2j.protocol.Database.Language.Execution.ExecAggregator"))
{
throw
StandardException.newException(SQLState.LANG_BAD_AGGREGATOR_CLASS2,
....
Maybe the message now needs to mention
org.apache.derby.iapi.sql.execute.ExecAggregator?
But, I think maybe this message cannot be obtained unless someone introduces a
bug within the Derby code. I think the reference to another internal class
should be removed. Or maybe the text of Cloudscape message 42Y31 can be used:
42Y31=LANG_BAD_AGGREGATOR_CLASS="Aggregator class ''{0}'' for aggregate ''{1}''
on type {2} is inaccessable or does not exist."
XSDB8.D=DATA_MULTIPLE_JBMS_FORCE_LOCK ="WARNING: Derby (instance {0}) is
attempting to boot the database {1} even though Derby (instance {2}) may still
be active. Only one instance of Derby should boot a database at a time. Severe
and non-recoverable corruption can result if 2 instances of Derby boot on the
same database at the same time. The db2j.database.forceDatabaseLock=true
property has been set, so the database will not boot until the db.lck is no
longer present. Normally this file is removed when the first instance of Derby
to boot on the database exits, but it may be left behind in some shutdowns. It
will be necessary to remove the file by hand in that case. It is important to
verify that no other VM is accessing the database before deleting the db.lck
file by hand."
John Embretsen commented on this in DERBY-1838:
https://issues.apache.org/jira/browse/DERBY-1838#action_12434090
Indicating that not only should the message refer to
derby.database.forceDatabaseLock, but the replacement of parameters is not
happening either.
But I can not find a place where this message is generated, so maybe it can
just be removed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
