[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-866:
--------------------------------
Attachment: derby-866-09-ae-nativeAuthenticationServiceWithTests.diff
Attaching derby-866-09-ae-nativeAuthenticationServiceWithTests.diff. This adds
a first batch of tests to the previous rev of the patch. The new tests pass for
me on my desktop and on a JSR169 platform.
The full regression tests also passed for me except for an error in
ErrorMessageTest. ErrorMessageTest ran fine for me standalone. The error may
relate to recent work on DERBY-5564? Details at the end of this comment.
The new tests stress the following configurations for both embedded and
client/server: no authentication, NATIVE authentication, NATIVE+LOCAL
authentication. That's a total of 6 configurations.
Some test framework methods had to be changed to account for the fact that
there's a new authentication failure message raised when the credentials db
doesn't exist yet. Also SystemPropertyTestSetup now shuts down the engine
BEFORE changing the properties, rather than vice-versa. Doing those operations
in the original order fails if the property you are setting is the one which
enables NATIVE authentication. This is because engine shutdown is an operation
which must be authenticated and it can't be authenticated by the NATIVE
machinery if the credentials database hasn't been created yet.
Touches the following files in addition to the files touched by the previous
rev of the patch:
A
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java
M java/testing/org/apache/derbyTesting/junit/DriverManagerConnector.java
M java/testing/org/apache/derbyTesting/junit/BaseTestCase.java
M java/testing/org/apache/derbyTesting/junit/TestConfiguration.java
M java/testing/org/apache/derbyTesting/junit/SystemPropertyTestSetup.java
M java/testing/org/apache/derbyTesting/junit/DatabaseChangeSetup.java
M java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java
M java/testing/org/apache/derbyTesting/junit/DropDatabaseSetup.java
---------------------------------
Here is the error I saw in ErrorMessageTest:
There was 1 failure:
1)
testDeadlockTimeout(org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest)junit.framework.ComparisonFailure:
Not a deadlock expected:<40[00]1> but was:<40[XL]1>
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:790)
at
org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest.testDeadlockTimeout(ErrorMessageTest.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: java.sql.SQLTransactionRollbackException: A lock could not be
obtained within the time requested. The lockTable dump is:
Wed Jan 18 11:51:46 PST 2012
XID |TYPE |MODE|LOCKCOUNT|LOCKNAME
|STATE|TABLETYPE / LOCKOBJ
|INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
333883 |ROW |S |0 |(1,7)
|WAIT |T
|NULL |T
|
*** The above row is the victim ***
333883 |ROW |X |3 |(1,8)
|GRANT|T
|NULL |T
|
333879 |ROW |S |0 |(1,8)
|WAIT |T
|NULL |T
|
333879 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |ROW |X |3 |(1,7)
|GRANT|T
|NULL |T
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:89)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2331)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
at
org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(EmbedResultSet.java:4406)
at
org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:472)
at
org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:376)
at org.apache.derbyTesting.junit.JDBC.assertDrainResults(JDBC.java:678)
at org.apache.derbyTesting.junit.JDBC.assertDrainResults(JDBC.java:655)
at
org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest$2.run(ErrorMessageTest.java:148)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.sql.SQLException: A lock could not be obtained within the time
requested. The lockTable dump is:
Wed Jan 18 11:51:46 PST 2012
XID |TYPE |MODE|LOCKCOUNT|LOCKNAME
|STATE|TABLETYPE / LOCKOBJ
|INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
333883 |ROW |S |0 |(1,7)
|WAIT |T
|NULL |T
|
*** The above row is the victim ***
333883 |ROW |X |3 |(1,8)
|GRANT|T
|NULL |T
|
333879 |ROW |S |0 |(1,8)
|WAIT |T
|NULL |T
|
333879 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |ROW |X |3 |(1,7)
|GRANT|T
|NULL |T
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:42)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:122)
at
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
... 12 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested.
The lockTable dump is:
Wed Jan 18 11:51:46 PST 2012
XID |TYPE |MODE|LOCKCOUNT|LOCKNAME
|STATE|TABLETYPE / LOCKOBJ
|INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
333883 |ROW |S |0 |(1,7)
|WAIT |T
|NULL |T
|
*** The above row is the victim ***
333883 |ROW |X |3 |(1,8)
|GRANT|T
|NULL |T
|
333879 |ROW |S |0 |(1,8)
|WAIT |T
|NULL |T
|
333879 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IX |2 |Tablelock
|GRANT|T
|NULL |T
|
333883 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |TABLE |IS |1 |Tablelock
|GRANT|T
|NULL |T
|
333879 |ROW |X |3 |(1,7)
|GRANT|T
|NULL |T
|
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:278)
at
org.apache.derby.impl.services.locks.Timeout.createException(Timeout.java:147)
at
org.apache.derby.impl.services.locks.Timeout.buildException(Timeout.java:246)
at
org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:613)
at
org.apache.derby.impl.services.locks.AbstractPool.lockObject(AbstractPool.java:119)
at
org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(ConcurrentPool.java:28)
at
org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(RowLocking2.java:165)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:520)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(HeapController.java:638)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(B2IRowLocking3.java:309)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(B2IRowLocking3.java:599)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(B2IRowLockingRR.java:105)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:305)
at
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(BTreeScan.java:1599)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(TableScanResultSet.java:577)
at
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(IndexRowToBaseRowResultSet.java:373)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:478)
at
org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:432)
... 5 more
FAILURES!!!
Tests run: 11906, Failures: 1, Errors: 0
> Derby User Management Enhancements
> ----------------------------------
>
> Key: DERBY-866
> URL: https://issues.apache.org/jira/browse/DERBY-866
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.2.1.6
> Reporter: Francois Orsini
> Assignee: Rick Hillegas
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
> UserManagement.html, UserManagement.html, UserManagement.html,
> UserManagement.html, derby-866-01-aa-sysusers.diff,
> derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff,
> derby-866-03-aa-resetModifyPassword.diff,
> derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff,
> derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff,
> derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff,
> derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff,
> derby-866-09-ad-nativeAuthenticationService.diff,
> derby-866-09-ae-nativeAuthenticationServiceWithTests.diff,
> dummyCredentials.properties
>
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec
> attached to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by
> providing a more intuitive and familiar DDL interface. Currently (in
> 10.1.2.1), Built-In users can be defined at the system and/or database level.
> Users created at the system level can be defined via JVM or/and Derby system
> properties in the derby.properties file. Built-in users created at the
> database level are defined via a call to a Derby system procedure
> (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
> Defining a user at the system level is very convenient and practical during
> the development phase (EOD) of an application - However, the user's password
> is not encrypted and consequently appears in clear in the derby.properties
> file. Hence, for an application going into production, whether it is embedded
> or not, it is preferable to create users at the database level where the
> password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing
> a more intuitive and known interface, it will ease Built-In User management
> at the database level as well as Derby's adoption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
