from:"Francois Orsini"

[
https://issues.apache.org/jira/browse/DERBY-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758362#action_12758362
]

Francois Orsini commented on DERBY-4377:

Hi Kim,

Thanks for taking care of it.

It looks good - just some minor changes to consider.

If you have enabled Derby's BUILTIN user authentication and created some user
at the system level (for example, by setting some username and password in the
derby.properties file), you will need to specify credentials (e.g. username and
password) in order to shut down a Derby system.

Developer's Guide statement on shutting down Derby needs qualification
--

Key: DERBY-4377
URL: https://issues.apache.org/jira/browse/DERBY-4377
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.5.3.0
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
Attachments: DERBY-4377.diff, tdevdvlp40464.html

The topic Shutting down Derby or an individual database
(http://db.apache.org/derby/docs/dev/devguide/tdevdvlp40464.html) begins,
Applications in an embedded environment shut down the Derby system by
specifying the shutdown=true attribute in the connection URL. To shut down
the system, you do not specify a database name, and you must not specify any
other attribute.
This statement actually needs some qualification, because (according to
Francois Orsini) if you have defined Derby's BUILT-IN user authentication at
the System level (e.g. setting username / password in derby.properties file)
you do need to specify a username and password when you shut down the
database.
The topic needs to include this information. Further suggestions on the
wording are welcome.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4377) Developer's Guide statement on shutting down Derby needs qualification


[ 
https://issues.apache.org/jira/browse/DERBY-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758406#action_12758406
 ] 

Francois Orsini commented on DERBY-4377:


Hi Kim,

Thanks for the prompt turnaround ;-)

Just a minor nit:

I would replace:

If you have defined Derby BUILTIN user authentication

with:

If you have enabled Derby BUILTIN user authentication

Thanks

 Developer's Guide statement on shutting down Derby needs qualification
 --

 Key: DERBY-4377
 URL: https://issues.apache.org/jira/browse/DERBY-4377
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.5.3.0
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-4377-2.diff, DERBY-4377.diff, tdevdvlp40464.html, 
 tdevdvlp40464.html


 The topic Shutting down Derby or an individual database 
 (http://db.apache.org/derby/docs/dev/devguide/tdevdvlp40464.html) begins,
 Applications in an embedded environment shut down the Derby system by 
 specifying the shutdown=true attribute in the connection URL. To shut down 
 the system, you do not specify a database name, and you must not specify any 
 other attribute.
 This statement actually needs some qualification, because (according to 
 Francois Orsini) if you have defined Derby's BUILT-IN user authentication at 
 the System level (e.g. setting username / password in derby.properties file) 
 you do need to specify a username and password when you shut down the 
 database.
 The topic needs to include this information. Further suggestions on the 
 wording are welcome.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-4377) Developer's Guide statement on shutting down Derby needs qualification


[ 
https://issues.apache.org/jira/browse/DERBY-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758406#action_12758406
 ] 

Francois Orsini edited comment on DERBY-4377 at 9/22/09 1:11 PM:
-

Hi Kim,

Thanks for the prompt turnaround ;-)

Just a minor nit, sorry:

I would replace:

If you have defined Derby BUILTIN user authentication

with:

If you have enabled Derby BUILTIN user authentication

Thanks

  was (Author: forsini):
Hi Kim,

Thanks for the prompt turnaround ;-)

Just a minor nit:

I would replace:

If you have defined Derby BUILTIN user authentication

with:

If you have enabled Derby BUILTIN user authentication

Thanks
  
 Developer's Guide statement on shutting down Derby needs qualification
 --

 Key: DERBY-4377
 URL: https://issues.apache.org/jira/browse/DERBY-4377
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.5.3.0
Reporter: Kim Haase
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-4377-2.diff, DERBY-4377.diff, tdevdvlp40464.html, 
 tdevdvlp40464.html


 The topic Shutting down Derby or an individual database 
 (http://db.apache.org/derby/docs/dev/devguide/tdevdvlp40464.html) begins,
 Applications in an embedded environment shut down the Derby system by 
 specifying the shutdown=true attribute in the connection URL. To shut down 
 the system, you do not specify a database name, and you must not specify any 
 other attribute.
 This statement actually needs some qualification, because (according to 
 Francois Orsini) if you have defined Derby's BUILT-IN user authentication at 
 the System level (e.g. setting username / password in derby.properties file) 
 you do need to specify a username and password when you shut down the 
 database.
 The topic needs to include this information. Further suggestions on the 
 wording are welcome.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4377) Developer's Guide statement on shutting down Derby needs qualification

[
https://issues.apache.org/jira/browse/DERBY-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12758431#action_12758431
]

Francois Orsini commented on DERBY-4377:

Looks great, Kim. Thanks for taking care of it! +1

Developer's Guide statement on shutting down Derby needs qualification
--

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Reg:Accessing database.jar file using derby10.2.2.0

2009-09-21 Thread Francois Orsini

Hi Gana,

Have you checked file permissions on derby.jar to make sure it is readable
by whomever user that is launching tomcat?

Also, you could test with putting the jars under tomcat/lib

--francois

On Mon, Sep 21, 2009 at 6:48 AM, gana prasad gana.m...@gmail.com wrote:

 Hi,

 I am facing the problems while accessing the database jar file using derby
 10.2.2.0.

 I am getting the Exception as below:
 *

  org.apache.tomcat.dbcp.dbcp.SQLNestedException
 *: Cannot load JDBC driver class 'org.apache.derby.jdbc.EmbeddedDriver'

 at org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(
 *BasicDataSource.java:1136*)

 at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(
 *BasicDataSource.java:880*)  



 My configuration as shown below:

 Context.xml:

 
 Context crossContext=*true*

Resource name=*jdbc/derby* auth=*Container*

 type=*javax.sql.DataSource* driverClassName=*
 org.apache.derby.jdbc.EmbeddedDriver*

 url=*jdbc:derby:jar:(c:\CalypsoDemo\database.jar)samples*

 username=*xxx* password=*xxx* maxActive=*20* maxIdle=*10*

maxWait=*-1*/

 /
 Context



 And in my code i am accessing the database like this:

   Context initContext = *new* InitialContext();

   Context envContext = (Context)initContext.lookup(
 java:/comp/env);

   DataSource ds = (DataSource)envContext.lookup(
 jdbc/derby);

   conn = ds.getConnection();

 And i have placed the derby jar file in tomcat/common/lib  directory. And
 database.jar file in my local directory.



 What could be the reason for this ? Is there any problem with my
 configuration.?



 Please help me in this regard,



 Thanks in Advance,

 Gana.

[jira] Commented: (DERBY-4360) Avoid memory exhaustion when running UpgradeTrajectoryTest w/-DderbyTesting.allTrajectories=true

2009-09-15 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12755637#action_12755637
 ] 

Francois Orsini commented on DERBY-4360:


It might also be interesting to generate a heap dump 
(-XX:+HeapDumpOnOutOfMemoryError) and profile it using jhat or VisualVM to 
verify what's really being accumulated onto the heap.

Either one of the 2 proposals sounds good - #2 might be best for a shorter 
overall test time duration.

 Avoid memory exhaustion when running UpgradeTrajectoryTest 
 w/-DderbyTesting.allTrajectories=true
 

 Key: DERBY-4360
 URL: https://issues.apache.org/jira/browse/DERBY-4360
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Affects Versions: 10.6.0.0
 Environment: JVM:
 Sun Microsystems Inc.
 java version 1.5.0_14
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
 Java HotSpot(TM) Server VM (build 1.5.0_14-b03 mixed mode 32-bit)
Reporter: Ole Solberg

 When run with  -XX:MaxPermSize=1024m -Xmx1024m  
 -DderbyTesting.allTrajectories=true we get 'Exception in thread main 
 java.lang.OutOfMemoryError: Java heap space' after ~435 out of 4083 
 trajectories.
 When increasing to XX:MaxPermSize=1024m -Xmx2048m we reach ~930 out of 4083 
 trajectories,
 without OOM but with extreme upgrade times:
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.1.2.1 - 
 10.1.3.1 - 10.2.1.6 - 10.2.2.0 - 10.3.1.4 - 10.3.3.0 - 10.4.1.3 - 
 10.4.2.0 - 10.5.1.1 - 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, 
 hard, hard, hard, hard, hard )
 used 10809 ms .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.1.2.1 - 
 10.1.3.1 - 10.2.1.6 - 10.2.2.0 - 10.3.1.4 - 10.3.3.0 - 10.4.1.3 - 
 10.4.2.0 - 10.5.1.1 ( hard, hard, hard, hard, hard, hard, hard, hard, hard, 
 hard, hard )
 used 3871 ms .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.1.2.1 - 
 10.1.3.1 - 10.2.1.6 - 10.2.2.0 - 10.3.1.4 - 10.3.3.0 - 10.4.1.3 - 
 10.4.2.0 - 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, hard, hard, 
 hard, hard )
 used 3049 ms .
 .
 .
 .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.2.2.0 - 
 10.3.1.4 ( hard, hard, hard, hard )
 used 95779 ms .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.2.2.0 - 
 10.3.3.0 - 10.4.1.3 - 10.4.2.0 - 10.5.1.1 - 10.5.3.0 ( hard, hard, hard, 
 hard, hard, hard, hard, hard )
 used 167768 ms .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.2.2.0 - 
 10.3.3.0 - 10.4.1.3 - 10.4.2.0 - 10.5.1.1 ( hard, hard, hard, hard, hard, 
 hard, hard )
 used 148693 ms .
 testTrajectory DEBUG: Testing trajectory: 10.0.2.1 - 10.1.1.0 - 10.2.2.0 - 
 10.3.3.0 - 10.4.1.3 - 10.4.2.0 - 10.5.3.0 ( hard, hard, hard, hard, hard, 
 hard, hard )

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3501) Implement a JMX replicationMBean for monitoring of replication.

2009-09-11 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12754216#action_12754216
 ] 

Francois Orsini commented on DERBY-3501:


Knut, Rick, Thanks for the great comments.

I'm incorporating them and will post a new rev. Cheers.

 Implement a JMX replicationMBean for monitoring of replication.
 ---

 Key: DERBY-3501
 URL: https://issues.apache.org/jira/browse/DERBY-3501
 Project: Derby
  Issue Type: Improvement
  Components: JMX
Affects Versions: 10.6.0.0
Reporter: Bernt M. Johnsen
Assignee: Francois Orsini
 Attachments: ReplicationMonitoring_JMX_FS_v0_1.html


 Imlement a replicationMBean for monitoring of replication. Example attributes
 - master/slave state
 - replication buffer usage
 - replication network traffic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3501) Imlement a replicationMBean for monitoring of replication.


 [ 
https://issues.apache.org/jira/browse/DERBY-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-3501:
---

Attachment: ReplicationMonitoringFS_v1_0.html

Please find Attached a first rev of Functional Spec for Derby Replication 
Monitoring via JMX.

Comments are much appreciated.

 Imlement a replicationMBean for monitoring of replication.
 --

 Key: DERBY-3501
 URL: https://issues.apache.org/jira/browse/DERBY-3501
 Project: Derby
  Issue Type: Improvement
  Components: JMX
Reporter: Bernt M. Johnsen
 Attachments: ReplicationMonitoringFS_v1_0.html


 Imlement a replicationMBean for monitoring of replication. Example attributes
 - master/slave state
 - replication buffer usage
 - replication network traffic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3501) Imlement a replicationMBean for monitoring of replication.


 [ 
https://issues.apache.org/jira/browse/DERBY-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-3501:
---

Attachment: (was: ReplicationMonitoringFS_v1_0.html)

 Imlement a replicationMBean for monitoring of replication.
 --

 Key: DERBY-3501
 URL: https://issues.apache.org/jira/browse/DERBY-3501
 Project: Derby
  Issue Type: Improvement
  Components: JMX
Reporter: Bernt M. Johnsen

 Imlement a replicationMBean for monitoring of replication. Example attributes
 - master/slave state
 - replication buffer usage
 - replication network traffic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3501) Imlement a replicationMBean for monitoring of replication.


 [ 
https://issues.apache.org/jira/browse/DERBY-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-3501:
---

Attachment: ReplicationMonitoring_JMX_FS_v0_1.html

 Imlement a replicationMBean for monitoring of replication.
 --

 Key: DERBY-3501
 URL: https://issues.apache.org/jira/browse/DERBY-3501
 Project: Derby
  Issue Type: Improvement
  Components: JMX
Reporter: Bernt M. Johnsen
 Attachments: ReplicationMonitoring_JMX_FS_v0_1.html


 Imlement a replicationMBean for monitoring of replication. Example attributes
 - master/slave state
 - replication buffer usage
 - replication network traffic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3501) Implement a JMX replicationMBean for monitoring of replication.


 [ 
https://issues.apache.org/jira/browse/DERBY-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-3501:
---

Affects Version/s: 10.6.0.0
 Assignee: Francois Orsini
  Summary: Implement a JMX replicationMBean for monitoring of 
replication.  (was: Imlement a replicationMBean for monitoring of replication.)

 Implement a JMX replicationMBean for monitoring of replication.
 ---

 Key: DERBY-3501
 URL: https://issues.apache.org/jira/browse/DERBY-3501
 Project: Derby
  Issue Type: Improvement
  Components: JMX
Affects Versions: 10.6.0.0
Reporter: Bernt M. Johnsen
Assignee: Francois Orsini
 Attachments: ReplicationMonitoring_JMX_FS_v0_1.html


 Imlement a replicationMBean for monitoring of replication. Example attributes
 - master/slave state
 - replication buffer usage
 - replication network traffic

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4364) Cannot create an instance of generated class org.apache.derby.exe.acf81e0010x0123x6e25x38c2x00000616b5f80.

2009-08-31 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749735#action_12749735
 ] 

Francois Orsini commented on DERBY-4364:


You can store application logic (e.g. JAR files) in a Derby database and then 
set derby.database.classpath (database property) to let Derby's class loader 
know that classes that could not be loaded from the user's classpath, can be 
loaded from specific stored JARs in the database.

Note that the application logic would have to be part of a SQL Function, 
procedure or table function...

More information at:
http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevdeploy30736

 Cannot create an instance of generated class 
 org.apache.derby.exe.acf81e0010x0123x6e25x38c2x0616b5f80.
 --

 Key: DERBY-4364
 URL: https://issues.apache.org/jira/browse/DERBY-4364
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.5.3.0
 Environment: The program run well in my local machine's tomcat 
 server. but when I deployed into http://www.jhost.cn/, it failed. the env in 
 jhost are:
 Apache/2.2.11 mod_jk/1.2.25  
 Tomcat Version 5.5.27  
 JVM Version 1.5.0_11-b03  
 PHP Version 5.2.8  
 MySQL Ver 14.12 Distrib 5.0.67  
 phpMyAdmin Version information: 3.1.1 
Reporter: LiuZhenKe
Priority: Critical
   Original Estimate: 336h
  Remaining Estimate: 336h

 This issue is quite like issue DERBY-4142, but I think the root cause is 
 different.
 The java code which raise this error is:
 rs=stmt.executeQuery(SELECT ID FROM T_SYS_RS_PACKAGE_MASTER WHERE EXISTS 
 (SELECT * FROM T_VC_MASTER MA WHERE 
 MA.SUBCLASS_TABLE_NAME='T_SYS_RS_PACKAGE_MASTER' AND 
 MA.SUBCLASS_TABLE_ID=T_SYS_RS_PACKAGE_MASTER.ID AND 
 MA.NAME='+PackageName+'));
 The error message tells that create an instance of generated class 
 acf81e0010x0123x6e25x38c2x0616b5f80 fail caused by 
 java.lang.NoClassDefFoundError: 
 org/apache/derby/impl/sql/execute/GenericQualifier. But I see that this 
 GenericQualifier.class is put in derby.jar, which is put  in WEB-INF\lib 
 folder. so I guess this issue may be caused by the classloader switch 
 somewhere, may be in acf81e0010x0123x6e25x38c2x0616b5f80. the new 
 classloader may not able to find a class in WEB-INF\lib\derby.jar. Anyway, 
 just a guess
 error log is captured:
 java.sql.SQLException: Cannot create an instance of generated class 
 org.apache.derby.exe.acf81e0010x0123x6e25x38c2x0616b5f80.
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87)
   at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:223)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2201)
   at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:614)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:152)
   at 
 Concept.Resource.Server.derby.CCheckInResources.checkInResources(CCheckInResources.java:342)
   at 
 Concept.Resource.Server.derby.CCheckInResources.SubmitTransaction(CCheckInResources.java:223)
   at 
 Concept.Transaction.Server.CTransactionServer.doPost(CTransactionServer.java:722)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:269)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
   at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:301)
   at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283)
   at 
 org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56)
   at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189

[jira] Commented: (DERBY-4364) Cannot create an instance of generated class org.apache.derby.exe.acf81e0010x0123x6e25x38c2x00000616b5f80.

2009-08-31 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12749760#action_12749760
 ] 

Francois Orsini commented on DERBY-4364:


Storing application logic JAR files in the database is NOT going to help fix 
your issue which is more tied to Derby's internal generated classes not being 
fully loaded by the classloader. I did mention 'derby.database.classpath' as 
you were asking if Derby could load classes outside of the user's classpath.

You might want to check your environment regarding the user classpath and make 
sure the Derby JARs for that specific version (10.5.3), are correctly 
referenced with no conflicts with JARs from another Derby version.

Have you been able to run that query outside of the application server JVM 
context, such as a standalone Java program to see if it is loading / executing 
fine?

You might want to re-download Derby 10.5.3 and put the JARs in another / 
separate directory and set the classpath to point to these and check if you're 
still seeing the issue - check if you have other derby.jar somewhere in your 
environment / FileSystem that could potentially lead to conflicts.

 Cannot create an instance of generated class 
 org.apache.derby.exe.acf81e0010x0123x6e25x38c2x0616b5f80.
 --

 Key: DERBY-4364
 URL: https://issues.apache.org/jira/browse/DERBY-4364
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.5.3.0
 Environment: The program run well in my local machine's tomcat 
 server. but when I deployed into http://www.jhost.cn/, it failed. the env in 
 jhost are:
 Apache/2.2.11 mod_jk/1.2.25  
 Tomcat Version 5.5.27  
 JVM Version 1.5.0_11-b03  
 PHP Version 5.2.8  
 MySQL Ver 14.12 Distrib 5.0.67  
 phpMyAdmin Version information: 3.1.1 
Reporter: LiuZhenKe
Priority: Critical
   Original Estimate: 336h
  Remaining Estimate: 336h

 This issue is quite like issue DERBY-4142, but I think the root cause is 
 different.
 The java code which raise this error is:
 rs=stmt.executeQuery(SELECT ID FROM T_SYS_RS_PACKAGE_MASTER WHERE EXISTS 
 (SELECT * FROM T_VC_MASTER MA WHERE 
 MA.SUBCLASS_TABLE_NAME='T_SYS_RS_PACKAGE_MASTER' AND 
 MA.SUBCLASS_TABLE_ID=T_SYS_RS_PACKAGE_MASTER.ID AND 
 MA.NAME='+PackageName+'));
 The error message tells that create an instance of generated class 
 acf81e0010x0123x6e25x38c2x0616b5f80 fail caused by 
 java.lang.NoClassDefFoundError: 
 org/apache/derby/impl/sql/execute/GenericQualifier. But I see that this 
 GenericQualifier.class is put in derby.jar, which is put  in WEB-INF\lib 
 folder. so I guess this issue may be caused by the classloader switch 
 somewhere, may be in acf81e0010x0123x6e25x38c2x0616b5f80. the new 
 classloader may not able to find a class in WEB-INF\lib\derby.jar. Anyway, 
 just a guess
 error log is captured:
 java.sql.SQLException: Cannot create an instance of generated class 
 org.apache.derby.exe.acf81e0010x0123x6e25x38c2x0616b5f80.
   at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
   at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87)
   at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:223)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398)
   at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
   at 
 org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2201)
   at 
 org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:614)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:152)
   at 
 Concept.Resource.Server.derby.CCheckInResources.checkInResources(CCheckInResources.java:342)
   at 
 Concept.Resource.Server.derby.CCheckInResources.SubmitTransaction(CCheckInResources.java:223)
   at 
 Concept.Transaction.Server.CTransactionServer.doPost(CTransactionServer.java:722)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:269)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Subject.java:517

Re: first rev of release notes for 10.5.3.0

2009-08-07 Thread Francois Orsini

Hi Rick,

Release notes look great indeed.

My only comment would be to emphasize the fix to the wrong-results
regression fixed by [image: [WWW]] DERBY-4331.

Just my 0,02 cents.

--francois

On Fri, Aug 7, 2009 at 10:13 AM, Rick Hillegas richard.hille...@sun.comwrote:

 Rick Hillegas wrote:

 I'm attaching a first rev of release notes for 10.5.3.0. Please send me
 your edits before 9:00 am San Francisco time on Monday August 10. These
 release notes are basically the 10.5.2.1 version with the following edits:

 1) Changed 10.5.2.1 to 10.5.3.0

 2) Added a separate table to describe the extra delta between 10.5.3.0 and
 10.5.2.1

 3) Updated the Build Environment section with facts about my machine

 Thanks,
 -Rick



  Probably this would work better if I attached the release notes.



  Release Notes for Derby 10.5.3.0

 These notes describe the difference between Derby release 10.5.3.0 and the
 preceding release 10.5.1.1.


- Overview #122f5db3efcf9118_Overview
- New Features #122f5db3efcf9118_New+Features
- Bug Fixes #122f5db3efcf9118_Bug+Fixes
- Issues #122f5db3efcf9118_Issues
- Build Environment #122f5db3efcf9118_Build+Environment

  Overview

  Derby is a pure Java relational database engine using standard SQL and
 JDBC as its APIs.

 Derby functionality includes:

- Embedded engine with JDBC drivers
- Network Server
- Network client JDBC drivers
- Command line tools: ij (SQL scripting), dblook (schema dump) and
sysinfo (system info)

  New Features

  This is a bug fix release and also provides localization of new 10.5
 messages. No new features were added.

  Bug Fixes

 The following issues are addressed by Derby release 10.5.3.0. These issues
 are not addressed in the preceding, deprecated 10.5.2.0 release.
  *Issue Id**Description*  
 *DERBY-4331*http://issues.apache.org/jira/browse/DERBY-4331
 * Join returns results in wrong order*  
 *DERBY-4312*http://issues.apache.org/jira/browse/DERBY-4312
 * SQLException XJ215 on insert with setCharacterStream() and autocommit
 off in mailjdbc test*  
 *DERBY-4306*http://issues.apache.org/jira/browse/DERBY-4306
 * NullPointerException in JMXManagementService.unregisterMBean when
 running jdbcapi._Suite*  
 *DERBY-4305*http://issues.apache.org/jira/browse/DERBY-4305
 *; Make changes to test harness class j9_foundation11 to support newer
 version of IBM's JSR169 implementation*  
 *DERBY-4292*http://issues.apache.org/jira/browse/DERBY-4292
 * creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not
 wrapped in privilege block which can cause problems running under
 SecurityManager*  
 *DERBY-4246*http://issues.apache.org/jira/browse/DERBY-4246
 *'.replicationTests.ReplicationRun_Local_3_p5).testReplication_Local_3_p5_DERBY_3878()'
 fails w/ Could not perform operation 'stopSlave' because the database '...'
 has not been booted.*  
 *DERBY-4270*http://issues.apache.org/jira/browse/DERBY-4270
 * Make replication tests save derby.log and database when a failure
 occurs.*  *DERBY-4203* 
 http://issues.apache.org/jira/browse/DERBY-4203*(partial) Change mailjdbc 
 system test to be able to restart with the
 existing database instead of creating a new one so it can be used for
 upgrade testing*  
 *DERBY-4186*http://issues.apache.org/jira/browse/DERBY-4186
 * After master stop, test fails when it succeeds in connecting (rebooting)
 shut-down ex-slave*  
 *DERBY-4185*http://issues.apache.org/jira/browse/DERBY-4185
 * Make timeout settable or increase default for one replication message
 layer protocol.*  
 *DERBY-4175*http://issues.apache.org/jira/browse/DERBY-4175
 * Instability in some replication tests under load, since tests don't wait
 long enough for final state or anticipate intermediate states*  *
 DERBY-4166* http://issues.apache.org/jira/browse/DERBY-4166* (partial)
 improvements to the mailjdbc test*  
 *DERBY-3921*http://issues.apache.org/jira/browse/DERBY-3921
 * Replication: Test replication of encrypted databases*  
 *DERBY-3814*http://issues.apache.org/jira/browse/DERBY-3814
 * - failure in testAssertFailureThreadDump with weme 6.1 / JSR 169*  *
 DERBY-3710* http://issues.apache.org/jira/browse/DERBY-3710*: cannot
 access a database using AES encryption with encryptionKeyLength=192 after
 it's been shutdown*

 The following additional issues are addressed by Derby release 10.5.3.0.
 These issues are not addressed in the preceding 10.5.1.1 release.
  *Issue Id**Description*  
 DERBY-4287http://issues.apache.org/jira/browse/DERBY-4287call
 to System.getProperty in BCClass.java is not wrapped in a priv block so may
 fail when running under SecurityManager  
 DERBY-4278http://issues.apache.org/jira/browse/DERBY-4278Batch
 inserts with Clobs fails with the embedded driver  
 DERBY-4276http://issues.apache.org/jira/browse/DERBY-4276Update
 demo's to remove references to com.ibm.db2.jcc.DB2Driver  
 DERBY-4274http://issues.apache.org/jira/browse/DERBY-4274SYSCS_UPDATE_STATISTICS
 takes unnecessary

[jira] Commented: (DERBY-3927) programmatic access to replication status

2009-08-06 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740349#action_12740349
 ] 

Francois Orsini commented on DERBY-3927:


We could also have a top level enhancement JIRA for Derby replication 
Monitoring in general and have these 2 JIRAs being sub-ones as different 
sub-tasks if having both approaches makes sense.

 programmatic access to replication status
 -

 Key: DERBY-3927
 URL: https://issues.apache.org/jira/browse/DERBY-3927
 Project: Derby
  Issue Type: Improvement
  Components: Replication
Affects Versions: 10.4.2.0
 Environment: N/A
Reporter: Andrew Lawrenson
Priority: Minor

 It would be very useful to be able to get programmatic information on the 
 current state of derby replication, from either the master or server nodes.
 this could be either via stored procedures, or JMX (my preference)
 this could be used, for example, to check if a master has exceeded its log 
 buffer after being disconnected from the slave.  Or to check if the slave is 
 still connected to the master.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Generating UUIDs

2009-06-09 Thread Francois Orsini

Hi Suran,

As defined in
https://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/services/uuid/BasicUUIDFactory.java

//  INITIAL_VALUE   =   a number guaranteeing that the first 
couple sequence numbers
//  won't be monotonically increasing.
...
...
private static  final   longINITIAL_VALUE   =   ( 2551218188L );
...
...

FYI,

--francois


On Tue, Jun 9, 2009 at 1:12 PM, Suran Jayathilaka suran...@gmail.comwrote:

 Thanks Rick. That did the trick. The 3rd argument is a random Long, is it
 not?

Re: Derby get together at CommunityOne?

2009-05-27 Thread Francois Orsini

Hi Kathey,

Yes, that would be great. I have read somewhere that a light lunch
(sandwiches) will also be included this year.

Some of us will also be at the Sun Java DB POD in the pavilion starting from
3pm, if you guys want to meet  discuss.

There is also a CommunityOne reception / party from 6-7pm

See you there

--francois

On Wed, May 27, 2009 at 11:25 AM, Kathey Marsden 
kmarsdende...@sbcglobal.net wrote:

 The agenda for CommunityOne shows a mid-day break from 12:40 - 1:40.  Would
 Derby folks like to gather for lunch?
 http://developers.sun.com/events/communityone/2009/west/agenda.jsp

 Last year they provided sandwiches and had tables set up which was nice. I
 don't know if we should bring our own lunch this time or if it will be
 provided. Does anyone know?

 Kathey

Re: Stored Prepared Statements? -- Thoughts on exposing StorablePreparedStatements to user/external statements

2009-04-17 Thread Francois Orsini

Hi Nick,

You can find information about how selectivity and cardinality statistics
are maintained by Derby at:

http://db.apache.org/derby/docs/dev/tuning/tuning-single.html#ctunstats18908

Cheers

--francois

On Fri, Apr 17, 2009 at 4:05 PM, Nick Puz nick.de...@me.com wrote:

  Hi Knut,

 Thanks for the response, I'll take a look into the cloudscape docs and how
 execute is implemented. I'll also look more at the statement cache to see
 about persisting it on shutdown and restoring on startup, so that then it
 could be done globally for all statements (as an option). Another
 alternative would be to let the user specify which to persist as a comment
 in the sql (as is done with the optimizer overrides to specify index usage,
 etc.), possibly as a different runtime option. The advantage of the first
 (global) is that apps could take advantage with no sql changes. Perhaps
 persist the N most recently used statements...

 In terms of invalidating, a crude but simple way would be to have the
 version of derby stored with the prepared statements and just to discard
 them if the version numbers differ. The same mechanism coudl be used as when
 deciding to recompile the system stored statements. What do you think?

 Besides version changes the statements should probably be
 removed/regenerated if the statistics used to determine the execution plan
 change. How does derby manage the statistics, are they automatically kept up
 to date or does the user have to do something specific? Do you happen to
 know what happens with the stored trigger actions, since they should have
 the same problem. I'll take a look at the code to try to figure it out in
 the next few days but just curious if you or another derby dev knows...

 -Nick

 On Friday, April 17, 2009, at 07:09AM, Knut Anders Hatlen
 knut.hat...@sun.com wrote:
 Nick Puz nick.de...@me.com writes:
 
  Hi Derby Developers,
 
  I'm evaluating derby for use in the backend of a internet (web+http
  direct) based service. We have a bunch of mid-tier app server type
  boxes that all access data mounted on a bunch of nfs filers (so any
  mid-tier can handle a user request) and so the current thinking is for
  usage pattern (mimicing what is done in other places in this 5+ year
  old live system) would be to:
  1) lock db directory for user (using symlinks -- atomic nfs op)
  ... would be done external to derby.
  2) open database for the user
  3) do operation to satisfy caller's request
  4) close db then remove lock.
 
  Unfortunately with this usage model the perf benefits of prepared
  statements go away (parameters still nicer then encoding for string
  sql stmts). I've done a bit of performance testing and as expected a
  ton of time is spent preparing a simple primary key lookup query
  (primarily due to opening/reading the many system tables and few
  indexes on the table), while the execution goes quite fast.
 
  In digging around the code I saw that the statements used for trigger
  actions are stored to remove this cost on each action invocation,
  would it be possible to expose this end user statements. In our case a
  mode that just keeps a persistent cache of the last N statements would
  be fine, no need to expose at all at the jdbc/sql level. I'm
  comfortable making the code change but would like to know before
  embarking on this the thoughts/advice of experienced derby developers.
 
 Hi Nick,
 
 I think you're right that it should be possible to build something on
 top of the stored prepared statements to get what you need. Cloudscape
 (Derby's predecessor) used to give you that functionality with CREATE
 STATEMENT and EXECUTE STATEMENT. The CREATE STATEMENT statement was
 removed from the code before it was donated to Apache, but EXECUTE
 STATEMENT is still there, so you can actually still do this to execute
 one of the statements stored in SYS.SYSSTATEMENTS:
 
 PreparedStatement ps =
conn.prepareStatement(execute statement sys.\getSchemas\);
 ps.setString(1, %);
 ps.setString(2, %);
 ResultSet rs = ps.executeQuery();
 
 The old CREATE STATEMENT syntax is described here:
 
 http://www.dwfa.ca/Library/Java/Cloudscape/v3.6.1/doc/html/coredocs/sqlj15.htm
 
 My guess is that it was removed because the SQL standard doesn't define
 a syntax for storing compiled statements (as far as I'm aware). If we
 find a solution to the problem with the lack of a standardized way to do
 it, I think such a functionality would be useful. (At least, I don't see
 why persisting user-defined statements should be less useful than
 persisting the meta-data queries, which we already do.)
 
 Persisting the statement cache on shutdown is an interesting thought,
 and it would be transparent to the users. It should probably be optional
 so that we don't start writing lots of data on shutdown for users that
 don't need/want it, and I'd guess there would be some upgrade concerns
 too. I think I'd prefer a per-statement solution, though, as it would
 give the user better

Re: Issues with SQL Roles

2009-04-04 Thread Francois Orsini

Hi Tiago,

Did you set 'derby.database.sqlAuthorization=TRUE' *before* creating the
database?

If not, you would have to specifically set it for this database using:
ij CALL
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.sqlAuthorization','true');

http://db.apache.org/derby/docs/dev/devguide/cdevcsecure866060.html

Otherwise, make sure your derby.properties is actually accessed by the Derby
instance - For example, try to connect with an incorrect password and see if
it denies the connection for a user.

--francois

On Sat, Apr 4, 2009 at 5:03 AM, Tiago Espinha ti...@espinhas.net wrote:

 Hi everyone,

 I am testing the SQL Roles for the 10.5 buddy testing and I'm facing
 some issues. By following the documentation, I have created the
 following derby.properties file:

 derby.connection.requireAuthentication=TRUE
 derby.database.sqlAuthorization=TRUE
 derby.authentication.provider=BUILTIN
 derby.user.adm=java
 derby.user.tiago=espinha

 Now, the steps I've followed afterwards (on ij) are:
  connect
 'jdbc:derby://localhost:1527/goodone;create=true;user=adm;password=java';

 And the database gets created properly. Then I proceed to create a
 test table, while still logged in as 'adm':
  create table t2 (f1 int, f2 varchar(20));

 Then I disconnect; from the server and connect back on, this time with
 the user 'tiago':
  connect
 'jdbc:derby://localhost:1527/goodone;user=tiago;password=espinha';

 At this point I am logged in but, opposed to what I would think, I
 have access to the table I just created with 'adm'. I do have to
 specify the 'adm' schema to access it but I do not have any
 restrictions whatsoever. I can INSERT, SELECT and even DROP the table
 without any restriction. By default I should not have any privileges
 at all over the table adm.t2 should I?

 Can someone help me out and tell me what exactly am I doing wrong?
 Keep in mind that I would like to have only the SQL authentication
 turned on.

 Thanks in advance,
 Tiago

Re: [GSoC] Derby Test and Fix

2009-03-16 Thread Francois Orsini

Hi Hiranya,

I believe Dag Wanvik will be at ApacheCon in Amsterdam this year. You guys
should be able to hook-up.

Cheers

--francois

On Sun, Mar 15, 2009 at 9:55 PM, Hiranya Jayathilaka
hiranya...@gmail.comwrote:

 Hi Folks,
 Sorry for not keeping you up-to-date on my progress. But I've been reading
 Derby documentation and trying out various test suites. I must say that
 Derby is one of the best documented open source projects I've ever
 encountered :) Really good work folks. I've tried out most of the test
 suites so far (I'm running them one by one) and I can already see a couple
 of test failures. I will post a detailed report on my observations very
 soon.

 Also I'd like to know that will any of you folks be at Amsterdam for
 upcoming ApacheCon? I'll be there and would love to get to know you devs
 better.

 Thanks,
 Hiranya


 On Sat, Mar 7, 2009 at 8:43 PM, Bryan Pendleton bpendle...@amberpoint.com
  wrote:

  code base. Since it is a fairly large code base I would appreciate some
 help in getting familiar with the code.


 Hello Hiranya, welcome to Derby!

 One place to get started is to look at the open issues in JIRA which have
 been flagged as newcomer:
 https://issues.apache.org/jira/browse/DERBY/component/12310640

 You might see something there which is interesting and suggests an initial
 place to explore.

 Another good thing to do is to verify that you can successfully build
 the code from scratch and run all the regression tests. The Derby
 regression
 suite is quite thorough, and you should be able to get a 100% pass rate.

 Let us know of your progress!

 bryan

[jira] Commented: (DERBY-646) In-memory backend storage support

2009-03-11 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681006#action_12681006
 ] 

Francois Orsini commented on DERBY-646:
---

+1. Having these (hooks) even as an experiment could be very useful while the 
in-memory feature is being tested.

I would probably wait after 10.5 because allowing for database deletion, but 
that is just me - just because there needs probably more time to investigate it 
and its possible side effects.

Maybe worth re-enforcing somewhere (notes if any) that the database is locked 
and its activity blocked while its estimated space usage is computed.

 In-memory backend storage support
 -

 Key: DERBY-646
 URL: https://issues.apache.org/jira/browse/DERBY-646
 Project: Derby
  Issue Type: New Feature
  Components: Store
Affects Versions: 10.5.0.0
 Environment: All
Reporter: Stephen Fitch
Assignee: Kristian Waagan
 Fix For: 10.5.0.0

 Attachments: derby-646-1a-raw-compiles.diff, 
 derby-646-1a-raw-compiles.stat, derby-646-20090222.diff, 
 derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff, 
 derby-646-2a-vfmem_first_rev.stat, derby-646-2b-vfmem_first_rev.diff, 
 derby-646-3a-jmx_experiment.diff, derby-646-performance_comparison_1a.txt, 
 svn.diff


 To allow creation and modification of databases in-memory without requiring 
 disk access or space to store the database.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-4084) Determine the subSubProtocol name for the in-memory back end

2009-03-11 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681013#action_12681013
 ] 

Francois Orsini commented on DERBY-4084:


+1 for 'memory'. To me it is descriptive enough and it says that if I have had 
writes to this database, I will loose them in case of a crash.

Note that other RDBMS supporting the in-memory mention in the JDBC connection 
URL such as h2 or hsqldb uses 'mem'.

 Determine the subSubProtocol name for the in-memory back end
 

 Key: DERBY-4084
 URL: https://issues.apache.org/jira/browse/DERBY-4084
 Project: Derby
  Issue Type: Sub-task
Affects Versions: 10.5.0.0
Reporter: Kristian Waagan

 The community should agree on a name for the subSubProtocol for the in-memory 
 back end. The name will be used in the connection URL, and it is the 
 mechanism used to tell Derby to use the in-memory back end:
 jdbc:derby:subSubProtocol:dbName
 Two hot candidates are:
  o mem
  o memory
 The former is shorter, the latter is slightly more descriptive. If you have 
 opinions on this, please post a comment.
 We should decide on this before we cut the branch for 10.5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Advantage of Derby Network Server versus Embedded Database

2009-02-05 Thread Francois Orsini

Hi,

If your 2 applications are running in the same Java Class Loader, then you
can just access the database with one Derby embedded instance.
On the other hand, if your applications are running in different Java class
loaders, you should start start Derby in Embedded Server mode and then have
the 2 applications accessing the database with the Derby JDBC Network Client
driver.
Note that you can also start a Derby instance in embedded mode with the
first application's class loader and then enable remote access (by turning
on Server mode[
http://db.apache.org/derby/docs/10.4/adminguide/tadminconfig814963.html])
within that embedded instance to enable the second application to connect
with the client driver.

Running Derby as a server in a separate process and different host machine
is usually better if the load is already going to be heavy on the
application server (middle-tier) - Trade-off is the network layer (overhead
due to data marshalling and unmarshalling  network latency) between the
application server and the Derby server if running standalone. Derby always
runs embedded, the server layer is really the client-server layer that
allows a remote client to connect to a Derby instance. The server layer can
itself run embedded in some application or as a standalone process...

So I'd say given your context that it is really a question of trade-off as
far if you can afford to have the database engine running embedded in your
application server, removing the network layer _but_  running in the same
JVM as the app server.

As I mentioned above, _if_ your applications are running in separate
(dedicated) Java class loaders, then you will need to have Derby's Server
mode enabled so that the second application accesses it via the JDBC network
client driver in TCP loopback mode. You can't have 2 Derby engine instances
going after the same database (no DB shared-disk cluster support).

Also, only having 1 Derby instance to handle mutliple databases only require
1 database cache for all DBs. Sorry if I sound like repeating myself but if
you can have Derby run embedded inside TomCat, then you can have your 2
applications using the embedded driver to access Derby for both databases (1
DB cache) _or_ if they are running in separate class loaders, you could have
Derby running in embedded server mode and have the second application use
Derby network client driver to access its database.

Hope this is somehow answering your question.

--francois

On Thu, Feb 5, 2009 at 7:51 AM, DerbyNoob thestarchi...@hotmail.com wrote:


 Hi,

 I have two java applications starting in one tomcat, with each of them
 using
 a derby database. My question is:
 is there an advantage when using the Network server with 2 databases, or is
 it wiser to use 2 embbeded drivers? Are there effincency, performance or
 load advantages when using the server?
 --
 View this message in context:
 http://www.nabble.com/Advantage-of-Derby-Network-Server-versus-Embedded-Database-tp21854157p21854157.html
 Sent from the Apache Derby Developers mailing list archive at Nabble.com.

[jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby

2008-09-03 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628139#action_12628139
 ] 

Francois Orsini commented on DERBY-3351:


Adding the link below as a note as it would be great to have a pluggable 
storage cookbook for Derby.
http://forge.mysql.com/wiki/MySQL_Internals_Custom_Engine

 Implement a Pluggable Storage Engine Architecture in Derby
 --

 Key: DERBY-3351
 URL: https://issues.apache.org/jira/browse/DERBY-3351
 Project: Derby
  Issue Type: New Feature
  Components: Services, SQL, Store
Reporter: Dibyendu Majumdar
Assignee: Dibyendu Majumdar

 My aim is to create a pluggable storage engine architecture for Derby, so 
 that the default store implementation can be replaced with alternative 
 storage engines. I have created my own storage engine which I would like to 
 use with Derby's SQL layer, so that is a motivation. But I also think that 
 this will benefit the community, and could lead to a pluggable storage engine 
 architecture similar to that of MySQL.
 I am not yet sure where the storage engine boundary should lie. I would 
 welcome input in this area.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: simpler api to the Derby store

2008-07-10 Thread Francois Orsini

On Mon, Jul 7, 2008 at 8:40 AM, Dag H. Wanvik [EMAIL PROTECTED] wrote:

 Knut Anders Hatlen [EMAIL PROTECTED] writes:

  although the API could need to be cleaned up and made easier. If someone
  wants to do such a cleanup, I think it would be good because
 
a) it may make Derby code that accesses the store simpler (easier to
understand, more maintainable)
 
b) it is easier for other projects to use Derby's store directly
without needing to fork Derby's code base (which potentially
increases Derby's user base and the chance of getting contributions
back from those projects)

 If the API were cleaner/easier, it would also make it more palatable
 to produce other backends for Derby. We have had attempts to make main
 memory backends; I am not sure why these never made it into
 production, though, could a backend API complexity be one reason?

 +1.

You mean something in the line of a Pluggable Storage Engine Architecture
like MySQL has
http://dev.mysql.com/doc/refman/5.1/en/pluggable-storage-overview.html

Re: simpler api to the Derby store

2008-07-03 Thread Francois Orsini

One of the things in particular that I always been a big fan about
Cloudscape (Derby) is its modular architecture:
http://db.apache.org/derby/papers/derby_arch.html (modules  services)

Yet, it has not been exploited so that it could benefit other projects and
allow other usage dimensions and contributions from outside Derby.

I have mentioned previously as part of this thread that I have heard many
requests of people wanting to re-use key Derby key components (modules) as
part of their own open source project, such as and not exclusively:

- Derby's SQL parser / compiler

- Derby's (B-Tree) Store.

The motivation for this is that a lot of Java developers know that Derby has
a solid (read mature) codebase that is strongly tested as well as a rather
active development community. It is a mature open source product. Stability,
maturity aspects are there and we know that lots of performance improvements
have been done for quite some time.

As of today, Derby in embedded mode brings a lot of value, especially in the
middle-tier where it can run as a whole (as some products use it already)
and perform well, Now as we know, there is a lot of innovation around data
management these days and I think some of the most recent initiatives could
benefit from Derby SQL processor and/or store components.
http://www.lexemetech.com/2008/06/hadoop-query-languages.html
(this is just one example)

I personally believe that even though Derby has a great modular
architecture, it needs to be more flexible to benefit (and non exclusively)
other Apache open source projects and at the end benefit the Derby community
itself (giving back). It would help promoting and increasing adoption and
contribution.

Let's say some open source projects are interested in re-using Derby's SQL
processor and/or Derby's B-Tree implementation, wouldn't it be better to
allow it (the flexible part) as the base for its architecture is already
there (the modularity part), or would it better to see other projects
ripping part of it because there is no easy way to do it and consequently
not being able to contribute back to Apache Derby? This happens everyday in
the open source world and very often does materialize as a fork.

By already having Derby's existing modular architecture and making it a bit
more flexible would lead to have a microkernel database type of architecture
and at the end it is a very good thing to have if you can claim this
(modularity + flexibility)). Combine this with the feature-rich aspect of
Derby, it opens up many more opportunities for Apache Derby and outside of
it. Derby's great modular architecture is (unfortunately) not exposed enough
for developers to benefit from it directly IMHO.

Mike's second point (single b-tree w/ a different codepath) is a clear
example of what could benefit other projects, not just Derby. We're not even
talking about some Derby Lite here but more like a flexible architecture
onto which we can build on top and generate even more adoption, leading to
more contribution. The microkernel aspect (which is not a new thing by the
way) opens up to a lot more opportunities in and out. This does not affect
Apache Derby core charter, in any way.

I just wanted to mention this as I see this as a positive aspect for Apache
Derby, its users and developers community and would bring interesting
opportunities outside.

Of course, this is some itch to scratch...and my view on this...

--francois

On Tue, Jul 1, 2008 at 12:52 PM, Rick Hillegas [EMAIL PROTECTED]
wrote:

 Hi Mike,

 Thanks for responding. Some comments inline...

 Mike Matrigali wrote:

 Bryan Pendleton wrote:

 be useful for applications which just need to put and get data by key
 value. These would be applications which don't need complex queries or SQL.


 Aren't there some pretty good packages for this already? E.g., BDB-JE,
 JDBM, Perst, etc.?

 Speaking totally personally, I'd sure like to see Derby focus on the
 things that make it special:
  - complete and correct JDBC implementation
  - complete and correct SQL implementation
  - low footprint, zero-admin reliable multi-user DBMS

 thanks,

 bryan

  I agree with bryan, I would rather see the Derby project concentrate on
 the stated goals of the project as Bryan enumerates.

 I do wonder if within this scope derby could do a better job of addressing
 the application paradigm of only needing single keyed
 access to a row of the form (short key, short data).  By being embedded

 I think that there are other usage patterns which are important to people
 who use these btree stores. It's not just single row key/value lookup
 although that's an important case. People also like to position an iterator
 on a btree and then march forward (or backward), updating and deleting as
 they go.

 derby already presents a better solution for a java application than
 a lot of databases.  So issues are:
 1) can we improve the jdbc implementation to make using it for a compiled
 plan close to as efficient as a non

Re: simpler api to the Derby store

2008-06-26 Thread Francois Orsini

Having talked to lots of Derby users and prospects at conferences and
elsewhere, I can only say that such addition / feature / hooks would be
quite welcome, indeed.

I'm at least aware of several open source projects (including some from
Apache) which would be interested in using Derby's B-Tree implementation for
the following reasons:

- It is 100% Java

- It is mature

- It performs well

- It is Apache

- It has an active community

There are also users who have a need for a simpler store (not SQL-based)
with a much lower footprint for restricted environments. Yes, they could use
other solutions out there but the Apache licensing scheme and community is
what bring them here in the first place.

On Thu, Jun 26, 2008 at 9:33 AM, Rick Hillegas [EMAIL PROTECTED]
wrote:

 Thanks for the quick response, Bryan. Some comments inline...

 Bryan Pendleton wrote:

 be useful for applications which just need to put and get data by key
 value. These would be applications which don't need complex queries or SQL.


 Aren't there some pretty good packages for this already? E.g., BDB-JE,
 JDBM, Perst, etc.?

 Right, there are other open-source offerings in this area. I think that
 Derby's feature set, maturity, and attractive license could occupy a unique
 spot in this space.


 Speaking totally personally, I'd sure like to see Derby focus on the
 things that make it special:
  - complete and correct JDBC implementation
  - complete and correct SQL implementation
  - low footprint, zero-admin reliable multi-user DBMS

 Absolutely, Derby should continue to be all of the above. But I think that
 a Derby Lite option could help us grow our community.

 Thanks,
 -Rick


 thanks,

 bryan

Re: DerbyDevActivities on the Derby wiki is outdated

2008-01-15 Thread Francois Orsini

On Jan 14, 2008 8:34 AM, Knut Anders Hatlen [EMAIL PROTECTED] wrote:

 Kristian Waagan [EMAIL PROTECTED] writes:

  Hello,
 
  Today I browsed around a little in the Derby wiki. I found this page:
  http://wiki.apache.org/db-derby/DerbyDevActivities
 
  The page was last edited 2006-08-19 21:52:27 by FrancoisOrsini, and
  is outdated.
  Shall we make an effort to bring it up to date, or are there other
  mechanisms users and developers can use to figure out what is going
  on?

 I think we get enough information by looking at the JIRA issues that are
 marked as In Progress and the release page, and effort is better spent
 on keeping those up to date.

  If there is no interest in updating it, and keeping it pretty updated,
  I suggest we delete it.

 Or perhaps just clearly label it as activities for Derby 10.2?


Just did.

[jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

2007-10-25 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537793
 ] 

Francois Orsini commented on DERBY-1823:


Latest changes look good Kim.

Yes it would be useful, in fact, connection authorization and SQL authorization 
(modes) can work together so one could expand these samples to add some 
grant/revoke statements for particular objects and restrict some users to be 
read-only ones at the connection level. Yes, it should be done under a separate 
JIRA IMHO. Cheers.

 Derby Developer's Guide -  Issues w/ User authentication and authorization 
 extended examples section/paragraph
 --

 Key: DERBY-1823
 URL: https://issues.apache.org/jira/browse/DERBY-1823
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
 10.3.1.4
Reporter: Francois Orsini
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-1823-2.diff, DERBY-1823-2.zip, DERBY-1823-3.diff, 
 DERBY-1823-3.zip, DERBY-1823-4.diff, DERBY-1823.diff, DERBY-1823.zip


 There is a couple of issues with the paragraph/section  User authentication 
 and authorization extended examples in the developer's guide
 http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
 1) The methods turnOnBuiltInUsers()  turnOffBuiltInUsers() do NOT shutdown 
 and reboot the database for which the 
 'derby.connection.requireAuthentication' authentication database property is 
 being set - as this last one is a derby static property, it will not be taken 
 into account until the database is rebooted (or the whole derby engine 
 instance). Hence, the 2 checks for Confirming requireAuthentication is 
 misleading as the property value is changed _but_ the actual database 
 authentication enabling/disabling has not changed since it was last booted. 
 Database needs to be shutdown and rebooted after 
 'derby.connection.requireAuthentication' is set and then some negative 
 testing of invalid user connection needs to be added to show that only valid 
 users can connect (in the case, authentication is being enabled).
 2) Paragraph (extended examples section) also needs to be moved at the same 
 level as the 2 above such as:
   User authentication example in a single-user, embedded environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
   User authentication example in a client/server environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
 since the extended examples (once fixed - see 1)) can be applied in both a 
 client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

2007-10-23 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537177
 ] 

Francois Orsini commented on DERBY-1823:


Changes look good Kim. I guess we want to inform the users that these samples 
are making use of Derby's built-in authentication mechanism (aka connection 
authorization in Derby) but they could also use ANSI SQL Standard GRANT/REVOKE 
object statements (aka SQL Authorization in Derby) and find more information by 
pointing them to 
http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevcsecure36595
Feel free to file a new JIRA if you think it is needed. I was just trying to 
make sure that by looking at these samples, users miss the fact that Derby also 
have support for GRANT/REVOKE.

 Derby Developer's Guide -  Issues w/ User authentication and authorization 
 extended examples section/paragraph
 --

 Key: DERBY-1823
 URL: https://issues.apache.org/jira/browse/DERBY-1823
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
 10.3.1.4
Reporter: Francois Orsini
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-1823-2.diff, DERBY-1823-2.zip, DERBY-1823-3.diff, 
 DERBY-1823.diff, DERBY-1823.zip


 There is a couple of issues with the paragraph/section  User authentication 
 and authorization extended examples in the developer's guide
 http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
 1) The methods turnOnBuiltInUsers()  turnOffBuiltInUsers() do NOT shutdown 
 and reboot the database for which the 
 'derby.connection.requireAuthentication' authentication database property is 
 being set - as this last one is a derby static property, it will not be taken 
 into account until the database is rebooted (or the whole derby engine 
 instance). Hence, the 2 checks for Confirming requireAuthentication is 
 misleading as the property value is changed _but_ the actual database 
 authentication enabling/disabling has not changed since it was last booted. 
 Database needs to be shutdown and rebooted after 
 'derby.connection.requireAuthentication' is set and then some negative 
 testing of invalid user connection needs to be added to show that only valid 
 users can connect (in the case, authentication is being enabled).
 2) Paragraph (extended examples section) also needs to be moved at the same 
 level as the 2 above such as:
   User authentication example in a single-user, embedded environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
   User authentication example in a client/server environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
 since the extended examples (once fixed - see 1)) can be applied in both a 
 client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

2007-10-23 Thread Francois Orsini

On 10/23/07, Richard Applebaum [EMAIL PROTECTED] wrote:

 How do I unsubscribe from this list?


Send an email to:
[EMAIL PROTECTED]

(as described per http://db.apache.org/derby/derby_mail.html)

Cheers

TIA

 Dick

[jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

2007-10-22 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536870
 ] 

Francois Orsini commented on DERBY-1823:


Great changes Kim. I tested all the samples and they worked great.

The only minor nit based on the write-ups is that you don't need the Derby jars 
to compile the samples. They are just required to run them. There's also a 
little step issue with the network client samples when it comes to shutting 
down the server at the end, which you should not have to do - if you do then we 
should tell the user to restart the server before running the samples.

So I would change: (for embedded)

Before you compile and run AuthExampleEmbedded.java, make sure that 
%DERBY_HOME%\lib\derby.jar (or $DERBY_HOME/lib/derby.jar) is in your classpath.

into --

Compile AuthExampleEmbedded.java
Before you run this program, make sure that %DERBY_HOME%\lib\derby.jar (or 
$DERBY_HOME/lib/derby.jar) is in your classpath.

and (for client-server)

Before you compile these programs, make sure that 
%DERBY_HOME%\lib\derbyclient.jar (or $DERBY_HOME/lib/derbyclient.jar) is in 
your classpath.

Before you run these programs, start Derby as described in Activity 4: Create 
and run a JDBC program using the client driver and Network Server in Getting 
Started with Derby. After you run the programs, stop Derby as described in the 
same topic.

into --

Compile AuthExampleClient1.java and AuthExampleClient2.java
Before you run these programs, make sure that %DERBY_HOME%\lib\derbyclient.jar 
(or $DERBY_HOME/lib/derbyclient.jar) is in your classpath,
then start Derby server as described in Activity 4, step 2: Create and run a 
JDBC program using the client driver and Network Server in Getting Started 
with Derby guide.

Another comment which is probably best treating in a separate JIRA is that we 
should probably document the fact that users can now use GRANT/REVOKE instead 
of Derby's non-standard built-in authorization implementation, but I would do 
this in a separate JIRA and at least point them to the Grant/Revoke 
documentation / samples.
See derby.database.sqlAuthorization property which was added as part of 
DERBY-464.
We could add something along these lines:
For more information about user authorization, see User authorizations in 
the Derby Developer's Guide
http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevcsecure36595

 Derby Developer's Guide -  Issues w/ User authentication and authorization 
 extended examples section/paragraph
 --

 Key: DERBY-1823
 URL: https://issues.apache.org/jira/browse/DERBY-1823
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
 10.3.1.4
Reporter: Francois Orsini
Assignee: Kim Haase
Priority: Minor
 Attachments: DERBY-1823-2.diff, DERBY-1823.diff, DERBY-1823.zip


 There is a couple of issues with the paragraph/section  User authentication 
 and authorization extended examples in the developer's guide
 http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
 1) The methods turnOnBuiltInUsers()  turnOffBuiltInUsers() do NOT shutdown 
 and reboot the database for which the 
 'derby.connection.requireAuthentication' authentication database property is 
 being set - as this last one is a derby static property, it will not be taken 
 into account until the database is rebooted (or the whole derby engine 
 instance). Hence, the 2 checks for Confirming requireAuthentication is 
 misleading as the property value is changed _but_ the actual database 
 authentication enabling/disabling has not changed since it was last booted. 
 Database needs to be shutdown and rebooted after 
 'derby.connection.requireAuthentication' is set and then some negative 
 testing of invalid user connection needs to be added to show that only valid 
 users can connect (in the case, authentication is being enabled).
 2) Paragraph (extended examples section) also needs to be moved at the same 
 level as the 2 above such as:
   User authentication example in a single-user, embedded environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
   User authentication example in a client/server environment
   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
 since the extended examples (once fixed - see 1)) can be applied in both a 
 client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3025) NPE when connecting to database with securityMechanism=8

2007-08-28 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523361
 ] 

Francois Orsini commented on DERBY-3025:


Interesting case indeed.

Patch looks good Knut. Thanks for fixing it.

+1 to commit

 NPE when connecting to database with securityMechanism=8
 

 Key: DERBY-3025
 URL: https://issues.apache.org/jira/browse/DERBY-3025
 Project: Derby
  Issue Type: Bug
  Components: Security
Affects Versions: 10.3.1.4
 Environment: Solaris x86
Reporter: Alan Burlison
Assignee: Knut Anders Hatlen
 Attachments: d3025-test.diff, d3025.diff, d3025.stat


 If derby.drda.securityMechanism has *not* been set to 
 STRONG_PASSWORD_SUBSTITUTE_SECURITY and the database is opened with the 
 securityMechanism=8 property set, a NPE is thrown:
 // Try opening the database.
 Properties props = new Properties();
 props.put(securityMechanism, 8);
 props.put(user, dbUser);
 props.put(password, dbPass);
 Connection db = null;
 try {
 StringBuilder sb = new StringBuilder(jdbc:derby:);
 sb.append(dbName);
 db = DriverManager.getConnection(sb.toString(), props);
 }
 // Handle exception
 } 
 java.lang.NullPointerException'. [XJ001]
 Caused by: java.sql.SQLException: Java exception: ': 
 java.lang.NullPointerException'.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown 
 Source)
 at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown 
 Source)
 at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
 Source)
 at 
 org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
 Source)
 at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
 Source)
 at org.apache.derby.impl.jdbc.EmbedConnection.init(Unknown Source)
 at org.apache.derby.impl.jdbc.EmbedConnection30.init(Unknown Source)
 at org.apache.derby.impl.jdbc.EmbedConnection40.init(Unknown Source)
 at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown 
 Source)
 at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
 at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
 at java.sql.DriverManager.getConnection(DriverManager.java:582)
 at java.sql.DriverManager.getConnection(DriverManager.java:154)
 at org.opensolaris.auth.db.DBManager.openDatabase(DBManager.java:152)
 ... 1 more
 Caused by: java.sql.SQLException: Java exception: ': 
 java.lang.NullPointerException'.
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
 at 
 org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
  Source)
 ... 16 more
 Caused by: java.lang.NullPointerException
 at 
 org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.substitutePassword(Unknown
  Source)
 at 
 org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl.authenticateUser(Unknown
  Source)
 at 
 org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(Unknown
  Source)
 at 
 org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(Unknown 
 Source)
 ... 10 more 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Optimization test result

2007-07-09 Thread Francois Orsini


Great. Seems to be in line with performance improvements reported by Olav
previously (especially on read-only operations):
http://www.nabble.com/10.3.1.0-beta-performance-tf4016873.html#a11410816

On 7/9/07, Manjula Kutty [EMAIL PROTECTED] wrote:


Hi,

I had run the optimization test and am attaching the report with 10.3beta. 
Looks like
10.3 performs better than 10.2 in query optimization. Please have a look

--
Thanks,
Manjula.

Re: NetworkServerControl shutdown w/ authentication failing?

2007-06-22 Thread Francois Orsini


On 6/22/07, Knut Anders Hatlen [EMAIL PROTECTED] wrote:


David Van Couvering [EMAIL PROTECTED] writes:

 I think invalid authentication is incorrect, because actually it
 should be this user is not authorized to shut down the database.
 The authentication went fine, it's just they aren't authorized.  There
 is security and there is being completely misleading.  The poor user
 will scratch their heads, like Martin did, wondering what on earth is
 wrong with their user and password, especially when they can log in to
 do other things.

Since the problem here is that the shutdown command in
NetworkServerControl does not pick up the user name or the password, I
think invalid authentication is correct. It tries to shut down the
database using the default user and no password when
derby.connection.requireAuthentication is true, hence it is not
authenticated (whereas the default user may or may not be authorized to
shut down the database).



Correct.


On 6/21/07, Francois Orsini [EMAIL PROTECTED] wrote:


 On 6/21/07, Knut Anders Hatlen [EMAIL PROTECTED] wrote:
  Martin Zaun [EMAIL PROTECTED] writes:

   - For better diagnostics, should the Invalid authentication
message
 tell the user name being used for authentication?

 We could have - this has been there for ages -  I think it was done
 originally for extra security ;-) One does not say anything about what
went
 wrong with the credentials, one just fails to authenticate and the
requester
 should know what to do to fix it (no guidance as far as what went wrong
-
 other databases also do this - I remember having looked at other RDBMS
but
 it was long ago).

I don't think adding the user name to the error message would reduce the
security. Sure, User 'APP' does not exist or Invalid password for
user 'APP' would be problematic, as they would reveal whether or not a
user existed. However, a message like Invalid authentication for user
'APP' would be OK since it doesn't say what went wrong, and it would be
more useful since Martin (or any other user) would immediately see that
the supplied user name had not been picked up.



Fair enough for the server (NetworkServerControl) - Yes, in this context it
is hard to find out which user has failed to authenticate. +1

--

Knut Anders

Re: NetworkServerControl shutdown w/ authentication failing?

2007-06-21 Thread Francois Orsini


On 6/21/07, Knut Anders Hatlen [EMAIL PROTECTED] wrote:


Martin Zaun [EMAIL PROTECTED] writes:

 Hi,

 there seems to be an issue with 'NetworkServerControl shutdown' and
 authentication.  Your comments appreciated.

 Here's what I'm doing:

[...]

 3) What does NOT work and results in a server crash: run shutdown
from NetworkServerControl with authentication (restarted server):

 java -Dderby.connection.requireAuthentication=true
  -Dderby.authentication.provider=BUILTIN
  -Dderby.user.MARTIN=martinspassword
  -Dderby.database.sqlAuthorization=true
  org.apache.derby.drda.NetworkServerControl shutdown

This command makes the server process terminate after this message:

 Derby shutdown warning:
  Connection refused : Invalid authentication.
 Apache Derby Network Server - 10.4.0.0 alpha - (549159M) shutdown at
2007-06-20
 22:52:59.093 GMT

Some printlns I put into
org.apache.derby.jdbc.InternalDriver.connect()
suggest that the wrong user name 'APP' (instead of 'MARTIN') is being
used for authentication:

 -- InternalDriver.connect()
 connect(): finfo = {shutdown=true}
 connect(): IdUtil.getUserNameFromURLProps(finfo) = APP


 Questions:

 - Was I using the authentication properties correctly for 'shutdown'?

I don't think the shutdown command recognizes these properties, but it
would be great if there were some way to set username/password for it.



That is correct, it does not - This is stepping into the realm of system
privileges - the SHUTDOWN operation is a  system privilege one. For
instance, one would not want *any* authenticated user to be able to shutdown
a server or a database if he/she is not authorized to do so (e.g. Admin
user).


- An authentication failure (Derby shutdown warning) should not result
   in the termination (or crash) of the server process, right?

Actually, the server doesn't crash, it just shuts down because it got a
shutdown command. The authentication failure is not for the server
shutdown, but for a clean-up operation (invoking a clean shutdown of the
database) performed during server shutdown. This clean-up is not
required for shutting down the server, it only makes the shutdown
cleaner (that is, we don't have to run recovery the next time we boot
the database). That's also why it's only a warning, not an error. Note
that the server shutdown only tries to shut down the database if the
server was started from the command line, otherwise the booted databases
are left running.

 - For better diagnostics, should the Invalid authentication message
   tell the user name being used for authentication?



We could have - this has been there for ages -  I think it was done
originally for extra security ;-) One does not say anything about what went
wrong with the credentials, one just fails to authenticate and the requester
should know what to do to fix it (no guidance as far as what went wrong -
other databases also do this - I remember having looked at other RDBMS but
it was long ago).


+1


--
Knut Anders

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

2007-05-31 Thread Francois Orsini


Yes, you are right - This is quite a corner case anyway and if it does
happen, proper action (such as removing the file physically) would have to
be done manually as in the case today (if running pre-1.4.2) which should
not be the case with 10.3 (if am not mistaken) - Hence, Derby will remove a
db lock file that has been kept around and recreate a new one the next time
it opens the DB _IF_ that one is not already lockedI suppose this would
apply there too...

On 5/31/07, Kathey Marsden [EMAIL PROTECTED] wrote:


Kathey Marsden wrote:
 Francois Orsini wrote:
 I haven't looked at the absolute latest changes and I was wondering
 if the case of a database being opened in a separate classloader and
 not having been shut down properly (due to unexpected exception in
 the application) could impede some other classloader to open the very
 same database due to the state of the dbex.lck file, not having been
 changed due to the exception in the other classloarder?
 I think this is a legitimate concern  (assuming I can get the thing
 working to prevent dual boot) as the System property and file contents
 would still match.  I'm not quite sure how to ensure proper cleanup in
 this case.  There once was a request that we have an option that the
 database shutdown if there were no connections.  That's about the only
 way I can see to resolve it.
Well the good news is I got the synchronization working.  On the cleanup
issue, I have been thinking about this case and I think that typically
an App Server is going to have one classloader per JDBC Provider.  For
example they might have two versions of Derby with different
classloaders accessing two different databases.  Typically if the
application is restarted it would be in the same Classloader I think.
Normal usage would not be to have two different Classloaders accessing
the same database.  For that network server would make more sense.

Kathey

Re: Cannot delete on many-to-many relationship

2007-05-30 Thread Francois Orsini


Hello Tuan,

How are you handing referential integrity in your application? are you using
triggers or are you using referential contraints (cascade deletes) - Would
be helpful if you could post a bit more details about your data schema
definitions or/and a reproducible case...

Thanks, --francois

On 5/29/07, Tuan Nguyen Minh [EMAIL PROTECTED] wrote:


 Hi all,

I'm a new user of derby. I have a problem want to support:

When executing the statement



em.createQuery(delete from Subject).executeUpdate();



where Subject is in a many-to-many relationship with Book, and Subject owns the 
relationship,

one expects that the corresponding entry in the SUBJECT_BOOK table would be 
deleted.  This

happens when bulk deleting one-to-many relationships that are mapped with a 
join table, as

well as for *-to-one relationships mapped with a foreign key.  It also happens 
when individually

deleting objects.  However, it does not happen when bulk deleting the owning 
side of a many-to-many

relationship.



Thanks  best regards,

Tuan Nguyen

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

2007-05-30 Thread Francois Orsini


I haven't looked at the absolute latest changes and I was wondering if the
case of a database being opened in a separate classloader and not having
been shut down properly (due to unexpected exception in the application)
could impede some other classloader to open the very same database due to
the state of the dbex.lck file, not having been changed due to the exception
in the other classloarder?

On 5/30/07, Kathey Marsden [EMAIL PROTECTED] wrote:


Daniel John Debrunner wrote:
 Kathey Marsden wrote:
 Daniel John Debrunner wrote:

 Actually string constants are by definition interned, so
 synchronized(DERBY_JVM_ID) is the same as
 synchronized(DERBY_JVM_ID.intern()) since DERBY_JVM_ID is a
 reference to a string constant. Though using intern() wouldn't harm
 and might make the code more readable.

 Silly question.  Would an interned string allow synchronization
 across classloaders?
 If not, how do I synchronize  two threads using different classloaders.
 Kathey

 Yes. The intern() provides a reference that will be identical
 regardless of any current class loader because the String class will
 only be loaded once by the jvm. You can google for other folks using
 the same trick, or using other objects that are guaranteed to be
 loaded once such as Integer.class, Integer.TYPE etc.

So I will assume then that my problem is

2) Since getting the exFileLock is not within the synchronized code. It
is possible that the state of the dbex.lck file on disk changes before
the boot.

I'll approach it from that angle.

Kathey

Re: Derby in the .orgZone at Java One

2007-05-02 Thread Francois Orsini


I should be able to do some as well Rick - I already have a badge.

On 4/27/07, Rick Hillegas [EMAIL PROTECTED] wrote:


Thanks to David and Lance for volunteering!

Cheers,
-Rick


Rick Hillegas wrote:
 Hi Derby dev folks,

 At this year's Java One, Derby will have some slots in the .orgZone.
 I've included a schedule below. This is in addition to the related
 presence of Java DB and Cloudscape in the Sun and IBM booths.

 I'm looking for a couple community members who'd be willing to sign up
 for these slots and share their knowledge of Derby with people who
 visit the .orgZone booth. I can get exhibitor passes for the lucky
 couple, which will let you trawl the Pavilion when you're not staffing
 the booth.

 If you're interested, please let me know by 4:00 pm San Francisco time
 this Friday, April 27. In your response, let me know which slots you
 prefer.

 Thanks!
 -Rick



 JavaOne ,orgZone Pavilion Hours:
 Tuesday, May 8: 11:30 am - 1:30 pm  [8] OpenJDK, Derby, Greenfoot,
 OO.org, woodstock, FSF, Funabol, ASF
 1:30 pm - 3:30 pm[8] OpenJDK, OO.org, FSF, JCP.org, Portal,
 Funabol, ASF, GlassFish
 3:30 pm - 5:30 pm[8] OpenLaszlo, Betavine, Hyperic, Woodstock,
 FSF, Portal, GlassFish, Zimbra
 5:30 pm - 7:30 pm[8] OpenJDK, Derby, PostgreSQL, OpenLaszlo,
 oo.org, FSF,  Zimbra, ASF
 7:30 pm - 8:30 pm[5] OpenJDK,  PostgreSQL, OO.org, FSF, ASF
 Wednesday, May 9: 11:30 am - 1:30 pm  [8] OpenJDK, Derby,
 Betavine, OO.org, Woodstock, Hyperic, Portal, ASF
 1:30 pm - 3:30 pm[8] OpenJDK, Derby, PostgreSQL, OpenLaszlo,
 OO.org, Woodstock, FSF, Zimbra
 3:30 pm - 4:30 pm[8]  OpenJDK, PostgreSQL, OO.org, Woodstock, FSF,
 JCP.org, Portal, ASF
 Thursday, May 10: 11:30 am - 1:30 pm  [8] OpenJDK, PostgreSQL,
 OO.org, FSF, JCP.org, Funabol, ASF, JCP.org
 1:30 pm - 3:30 pm[8] OpenJDK, Derby, PostgreSQL, Betavine, OO.org,
 FSF, ASF, Zimbra
 3:30 pm - 4:30 pm[4] OpenJDK, Derby, OO.org, FSF

Re: How to test StorageFactory/StorageFile implementations: help needed

2007-03-29 Thread Francois Orsini


Regarding A) You might want to look at some of the proposed and pending
changes for in-memory database / storage support:
https://issues.apache.org/jira/browse/DERBY-646

Check the very first comments as a possible way.

Btw, you might want to create a new JIRA entry (if none already exists) for
this new storage factory implementation. Just my 0.02 cents,

Regarding B) I guess you could also run the 'multi' (stress) test suite on
top of storeall

HTH

On 3/29/07, Luigi Lauro [EMAIL PROTECTED] wrote:


By checking the README.htm provided in the SVN testing directory, I
can see there is a storeall testing suite which seems to test the
storage area.

Now, given I'm working on a new StorageFactory implementation, I
would like to know 2 things:

A) How can I enable my storageFactory as default for testing? How can
I tell derby to use mine JNLPStorageFactory instead of default one?

B) How much can I trust these tests? How much do they stress the
StorageFile/StorageFactory implementations? They are 'large enough'
so that I can safely trust an implementation if all storeall is
passed, or Do i need to provide more, specific test-case in order to
be safe of my StorageFactory/StorageFile implementation?

Thanks a lot for any help you may give :)

Re: Derby minimum size tweaking: how far can I go?

2007-03-29 Thread Francois Orsini


On 3/27/07, Luigi Lauro [EMAIL PROTECTED] wrote:



On 27 Mar 2007, at 14:51, Oystein Grovlen - Sun Norway wrote:

 An empty database with just system tables etc has less than 70
 files/directories.
 Then you will use a few log files and maybe some property files so
 I would say that you will have about 175 files available for your
 own data.

Is it possible to cut down theses numbers both by # of files and
filesize? By disabling all the unneeded logging, disabling features,
forcing to write all logs to the same file, whatever. ANYTHING is
fine, if it cuts down number of files and filesize.

 The database will use one extra file for each table and index you
 create.

Ok, so file number grow linearly with the # of tables in the
database. Is there a way to reduce this number, by storing several/
all tables into one 'data' file?

 Do you need to do backups to the same system?  In that case, you
 will need to be able to store more than one copy of each file.

No, I don't need backup. This is a 'cache' of a remote database, so I
don't need ANYTHING at all, I just need to keep file number and file
size to the MINIMUM possible with Derby :)



Then I wonder if this feature (in-memory storage) would help solving  your
problem - at least, in respect with the number of generated files /
directories:
https://issues.apache.org/jira/browse/DERBY-646

Thanks a lot for the help :)

Re: How to test StorageFactory/StorageFile implementations: help needed

2007-03-29 Thread Francois Orsini


Luigi,

On 3/29/07, Francois Orsini [EMAIL PROTECTED] wrote:


Regarding A) You might want to look at some of the proposed and pending
changes for in-memory database / storage support:
https://issues.apache.org/jira/browse/DERBY-646

Check the very first comments as a possible way.



You would probably need to change some of the tests properties to use a
different default URL instead (if going the way it is mentioned in JIRA-646
and specify the storage factory to use)...

Btw, you might want to create a new JIRA entry (if none already exists) for

this new storage factory implementation. Just my 0.02 cents,



Saw that you're working on
http://issues.apache.org/jira/browse/DERBY-2469;-)  forget the above

Regarding B) I guess you could also run the 'multi' (stress) test suite on

top of storeall

HTH

On 3/29/07, Luigi Lauro [EMAIL PROTECTED] wrote:

 By checking the README.htm provided in the SVN testing directory, I
 can see there is a storeall testing suite which seems to test the
 storage area.

 Now, given I'm working on a new StorageFactory implementation, I
 would like to know 2 things:

 A) How can I enable my storageFactory as default for testing? How can
 I tell derby to use mine JNLPStorageFactory instead of default one?

 B) How much can I trust these tests? How much do they stress the
 StorageFile/StorageFactory implementations? They are 'large enough'
 so that I can safely trust an implementation if all storeall is
 passed, or Do i need to provide more, specific test-case in order to
 be safe of my StorageFactory/StorageFile implementation?

 Thanks a lot for any help you may give :)

Re: no protection of db boot - intended?

2007-02-27 Thread Francois Orsini


Hi Dag,

Not sure I understand this completely - What do you mean by Thus, an
invalid user is allowed to change the database state? if the database is
booted and left opened, it still requires users to authenticate to get a
valid connection to it, _if_ derby.connection.requireAuthentication was set
to true. The database can stay open as it is required to be online so that
user authentication works...Yes, we could shut it down again if it was not
being booted before *but* then one also has to handle the possibility of
concurrent user authentication requests and if the first one requiring the
db to be booted in the first place, should we shut it down then? I mean yes
we could do and try such a thing but it's not like the database data are
being made available since no invalid user will be able to authenticate
anyway...This is *not* a denial-of-service attack - Again, the db data is
not made available to invalid user(s)...

--francois

On 2/26/07, Dag H. Wanvik [EMAIL PROTECTED] wrote:



Working on DERBY-2264, I notice (again) that booting a database is not
protected in any way.  Currently, even when authentication
(derby.connection.requireAuthentication) is turned on, any user can
leave the database in a booted state: If not already booted, the
database potentially needs to be booted to authenticate. However, if
authentication fails, the database is not shut down again. Thus, an
invalid user is allowed to change the database state. I think this is
somewhat surprising for an end user. Is there a reason for this
behavior? If not, I will file a JIRA for fixing it.

Thanks,
Dag

Re: Q: Should Derby 10.3 be Derby 11?

2007-02-20 Thread Francois Orsini

Assuming you're not running Derby as an embedded server ;)

It would be great to have some backward compatibilty when running Derby
embedded local (no server mode), at a minimum...

On 2/20/07, David Van Couvering [EMAIL PROTECTED] wrote:

I would like to suggest we include the user community on this
discussion. It is the users who are most impacted by decisions around
security and compatibility.

Making the call that secure-by-default trumps frictionless upgrade
really needs to be done with their input and overall approval.

For example, if most people are using Derby embedded, then
secure-by-default in terms of authentication seems to me very low
priority. If I were a using Derby in embedded mode, and I were asked
which was more important, backward compatibility or secure by default, I
would definitely pick compatibility...

David

Rick Hillegas wrote:
Thanks for raising this issue, Bernt. Here's my $.02:

Making Derby secure-by-default is a high priority for many people on
this list. Since we're moving from wide-open, unsecure default behavior,
we have a lot of work to do. I expect we'll be making significant
security improvements for at least the next two feature releases. Once
we start advertising Derby as a secure database, I think we're committed
to closing security holes as they come up. I agree that we're changing
the network server disruptively. If this kind of change makes us bump to
a major release number, then I think we face the possibility that our
next several feature releases will all be major revisions.

There is an unhappy tension between frictionless-upgrade and
security-by-default. I don't think the proposed compatibility rules
address that tension:

http://wiki.apache.org/db-derby/ForwardCompatibility#head-fb84926793e6687822e8397203265a6497911efe

For instance, the third bullet under JVM Support and Version
Interoperability makes cross-rev network connections negotiate down to
the lower rev of the protocol even if the lower rev is less secure. That
seems wrong to me. Before voting on these guidelines, I think they
should be revised so that security-by-default trumps
frictionless-upgrade.

Regards,
-Rick

Bernt M. Johnsen wrote:
Hi,

I raise this question because it has now been introduced functionality
that will make Derby 10.3 not entirely compatible with 10.2.

It might seem innocent, but I think it deserves some discussion.

With the secure by default functionality, Rick H. has committed a
patch which requires me in my environment to start using the new
-unsecure option when a started a network server.

Consider the follwing quotes from two ongoing issues which describes
incompatible behaviour:

http://issues.apache.org/jira/browse/DERBY-2196 :

New Default Behavior - By default, the network server now comes up
with a Basic security policy. The customer may want to edit this
policy, using the demo/templates/server.policy template. Among other
side-effects, this may affect the running of customer-written
procedures and functions as well as other parts of the application
which run in the same VM with the engine. The customer may need to
instrument her code to run under a SecurityManager or she may need
to consider running with the security-disabling -unsecure option.

http://issues.apache.org/jira/browse/DERBY-2264 :

DBA Limits - The application may need to be changed to account for
the fact that only the Database Owner can shutdown, encrypt, and
upgrade a database.

So, the question is then: Is this a Derby 10 release, or should it
really be Derby 11?

Myself, I have no strong feelings, but wanted to raise the discussion.

Re: [jira] Resolved: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2007-02-08 Thread Francois Orsini


Excellent - Thanks for the port to 10.2.2.1, Knut.

On 2/8/07, Knut Anders Hatlen (JIRA) [EMAIL PROTECTED] wrote:



 [
https://issues.apache.org/jira/browse/DERBY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

Knut Anders Hatlen resolved DERBY-790.
--

   Resolution: Fixed
Fix Version/s: 10.3.0.0
   10.2.2.1

Committed fix to 10.2 with revision 504880.

 SQLException used by the networked interface to Derby is not
serializable

-

 Key: DERBY-790
 URL: https://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Fix For: 10.2.2.1, 10.3.0.0

 Attachments: derby-790-10.2.diff, DERBY-790-v1.diff,
DERBY-790-v1.stat, DERBY-790-v2.diff, DERBY-790-v2.stat, DERBY-790-v3.diff,
DERBY-790-v3.stat, DERBY-790-v5.diff, DERBY-790-v5.stat, Serialize.java


 When running RMI client tests with Derby,  many tests failed with the
following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error
response:
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be
performed on
 'SDF014B7' because it does not exist.' because exception ; nested
exception
 is:
 java.io.NotSerializableException:
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java
:191)
 at
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2007-02-07 Thread Francois Orsini (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-790:
--

Attachment: DERBY-790-v5.diff
DERBY-790-v5.stat

Thanks for the great review Knut.

I've removed the println() tracing statement and I'm now using reflection - I 
think this is fine as this is within some test method and as you mentioned, it 
is already used in some other method within that class.

Am running DerbyAll again and in the meantime I'm posting the new changes.

Cheers

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: https://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Attachments: DERBY-790-v1.diff, DERBY-790-v1.stat, DERBY-790-v2.diff, 
 DERBY-790-v2.stat, DERBY-790-v3.diff, DERBY-790-v3.stat, DERBY-790-v5.diff, 
 DERBY-790-v5.stat, Serialize.java


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: derby-dev lunch in February

2007-02-07 Thread Francois Orsini


Will be there. Thanks for setting this up.

On 2/7/07, Rick Hillegas [EMAIL PROTECTED] wrote:


Just a reminder that we're planning a Bay Area Derby lunch in San
Francisco next Wednesday, February 14. In case you haven't let me know
yet, please let me know by tomorrow if you're planning to attend. Anyone
can turn up, of course. I just want a short list of people to continue
the discussion about time and place.

Thanks,
-Rick

Rick Hillegas wrote:
 Geir Høydalsvik, a member of the Norwegian Derby team, will be
 visiting SF on February 14. I was hoping to use this as an excuse for
 a Bay Area Derby lunch. Please let me know if you can attend. Once we
 know who's coming, we can vote on a venue. Looking forward to seeing
 you all!

 Regards,
 -Rick

[jira] Commented: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2007-02-07 Thread Francois Orsini (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471080
 ] 

Francois Orsini commented on DERBY-790:
---

Thanks for the commit and great help Knut.

Yes I think it should be ported to 10.2 branch as well - This is a blocking 
issue for frameworks that need to do JDBC objects serialization  (i.e. via 
RMI). Changes are fairly low-risk as well. +1

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: https://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Attachments: DERBY-790-v1.diff, DERBY-790-v1.stat, DERBY-790-v2.diff, 
 DERBY-790-v2.stat, DERBY-790-v3.diff, DERBY-790-v3.stat, DERBY-790-v5.diff, 
 DERBY-790-v5.stat, Serialize.java


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discuss early code in Jira or on derby-dev?

2007-02-07 Thread Francois Orsini


+1

On 2/7/07, Rick Hillegas [EMAIL PROTECTED] wrote:


Hi Jean,

I'm getting to be a very big fan of conducting discussions in JIRA, for
the following reasons:

1) It's a great place to hang code samples and specs, which you might
not want to broadcast as hundreds of copies.

2) It's a great place to consolidate all of the conversations about a
particular issue.

3) It nevertheless turns into email to derby-dev. But the email is
pre-tagged with an identifying JIRA number, which helps people filter
out the conversations that interest them.

Sometimes, I find, it's helpful to start a conversation in JIRA and then
advertise it on derby-dev via a short post with a catchy subject.

Cheers,
-Rick

Jean T. Anderson wrote:
 I'm working on a CallableTest.java to convert derbynet/callable.java to
 junit.

 I would like to post an early, very incomplete version (just a few
 tests) to make sure I have the overall structure for junit correct up
front.

 Should I post a patch and start the conversation on derby-dev?
 Or open a Jira issue and have the conversation in that issue?

 I see a couple styles going, so figured I would ask.

 thanks,

  -jean

[jira] Updated: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2007-02-02 Thread Francois Orsini (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francois Orsini updated DERBY-790:
--

Attachment: DERBY-790-v3.diff
DERBY-790-v3.stat

Comments for this patch have been taken care of - The reproducible test case 
(Serialize.java) is also passing. New tests that got added are also passing.

If someone could test a full and partial build with the changes I would 
appreciate - at some point, it uses to compile fine with a full clean build and 
then I saw some class dependencies build issue on a partial build - I can no 
longer reproduce it but I'd like to make sure there is no build issue.

Thanks in advance,

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: https://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Attachments: DERBY-790-v1.diff, DERBY-790-v1.stat, DERBY-790-v2.diff, 
 DERBY-790-v2.stat, DERBY-790-v3.diff, DERBY-790-v3.stat, Serialize.java


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2006-10-06 Thread Francois Orsini (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-790?page=all ]

Francois Orsini updated DERBY-790:
--

Attachment: DERBY-790-v2.stat
DERBY-790-v2.diff

Knut,

Thanks for the review on this patch.

I've incorporated all the suggestions and increased the amount of test logic as 
far as comparing the original exception with the serialized one.

As part of the test logic in SqlExceptionTest.java, I'm now also using a batch 
to execute several batch elements and hence generate a few chained / nested 
exceptions.

I've tested under 1.3, 1.4, 1.5  1.6 Java runtime environments as well as 
under DerbyNetClient and DerbyNet frameworks as well as well as no framework.

I have tested and called getMessage() several times for _each_ of the 
serialized exceptions generated from the BatchUpdateException and I'm not 
getting the behavior you described - I get the exact same message than the 
original exception with no added string. The comparison of both the original 
and the serialized exceptions is thoroughly tested in 
BaseJDBCTestCase.java:assertSQLExceptionEquals() and that includes any chained 
exceptions.

Hence, I'm not sure how you got into the case you described and I would 
appreciate if you could post the logic for the test you ran as well as your 
java and platform environment.

In the meantime, I have attached the new changes.

Thanks,

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: http://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Fix For: 10.2.2.0

 Attachments: DERBY-790-v1.diff, DERBY-790-v1.stat, DERBY-790-v2.diff, 
 DERBY-790-v2.stat


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

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

[jira] Updated: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2006-09-26 Thread Francois Orsini (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-790?page=all ]

Francois Orsini updated DERBY-790:
--

Attachment: DERBY-790-v1.stat
DERBY-790-v1.diff

I have attached some patch to address DERBY-790.

I have added a new test as part of derbynet/SqlExceptionTest.java (junit test) 
and made sure it ran fine under the derbynet and derbynetclient frameworks - I 
have also made sure that the issue reported by DERBY-790 is indeed fixed by the 
change reflected in - This fix is much simpler than it originally was and 
thanks to the changes into client/am/SqlException.java which recursively create 
a SQLException object out of a SqlException one...The risk of this fix is 
minimal.

Basically, I have made Sqlca SqlException attribute a transient one as it is 
mostly and only required when the SQLException gets created through recursion 
before returning it to the client - Sqlca does not need to be serialized, once 
the SQLException has been constructed out of getSQLException() in 
SqlException.java; hence a client can go ahead and serialize it.

The cause of the NotSeriazableException was due to the fact that we stick the 
SqlException object in the init 'cause' of the SQLException (Throwable), and 
during serialization, the exception would be raised against Sqlca.

Cheers. --francois

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: http://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Fix For: 10.2.2.0

 Attachments: DERBY-790-v1.diff, DERBY-790-v1.stat


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

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

[jira] Commented: (DERBY-790) SQLException used by the networked interface to Derby is not serializable

2006-09-14 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-790?page=comments#action_12434700 ] 

Francois Orsini commented on DERBY-790:
---

   Did your re-verification show any problems? 

I had expanded the current SqlExceptionTest.java but realized the added logic 
was not proper in order to verify the fix is working. I added a test to 
SqlExceptionTest.java which is aimed at running in a true client/server 
environment and this is what I need to verify to ensure the fix is tested in a 
proper manner.

   Do you think the fix will make it into 10.2?

Yes.

 SQLException used by the networked interface to Derby is not serializable
 -

 Key: DERBY-790
 URL: http://issues.apache.org/jira/browse/DERBY-790
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client, Network Server
Affects Versions: 10.1.1.0
 Environment: Windows XP; WebLogic Server 9.0
Reporter: David Cabelus
 Assigned To: Francois Orsini
 Fix For: 10.2.1.0


 When running RMI client tests with Derby,  many tests failed with the 
 following message:
 Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
 'SDF014B7' because it does not exist.' because exception ; nested exception 
 is:
 java.io.NotSerializableException: 
 org.apache.derby.client.net.NetSqlca
 at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
 at 
 weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
 This issue is a blocking issue for us.

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

[jira] Assigned: (DERBY-926) Protocol error when trying to connect with an unsupported security mechanism

2006-09-12 Thread Francois Orsini (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-926?page=all ]

Francois Orsini reassigned DERBY-926:
-

Assignee: Francois Orsini

 Protocol error when trying to connect with an unsupported security mechanism
 

 Key: DERBY-926
 URL: http://issues.apache.org/jira/browse/DERBY-926
 Project: Derby
  Issue Type: Bug
  Components: Network Client, Network Server
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 
 10.1.2.0, 10.1.2.1, 10.1.2.2, 10.2.1.0, 10.1.3.0, 10.1.2.3, 10.0.2.2
 Environment: all
Reporter: Sunitha Kambhampati
 Assigned To: Francois Orsini
Priority: Minor

 1) Start network server on port
 2) In ij, try to connect using the securityMechanism=12
  ij(CONNECTION2) connect 
 'testdb;create=true;securityMechanism=12;user=sa;password=p1';
 ERROR 58009: Execution failed due to a distribution protocol error that 
 caused deallocation of the conversation.  A PROTOCOL Data Stream Syntax Error 
 was detected.  Reason: 0x12

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

Re: Compiling 10.2 Release Notes

2006-09-12 Thread Francois Orsini

On 9/12/06, Rick Hillegas [EMAIL PROTECTED] wrote:
At some point, I will need to bundle Release Notes into the 10.2distributions. Here's a proposal for what I need to do:1) Create a new top-level text file next to LICENSE and README. I'd liketo call this file RELEASE-NOTES.

Minor nit but it should probably be RELEASE-NOTES.txt (note the added
extension) - This is what am seeing from other Apache projects. You may
have meant it already implicitly.
2) Fill up this file with the following three sections:a) Features. These would be brief descriptions culled from the summary
table on the snapshot wiki page:http://wiki.apache.org/db-derby/TenTwoSnapshot
Probably something like 'New features'
b) Release notes proper. These would be the release notes visiblethrough the following JIRA filter:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311198.Currently, 22 notes appear in this filter.
3) Bug fixes. These would be the one line summaries from issues visiblethrough the following JIRA filter:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12311199.Currently, 373 issues appear in this filter. I think I can discard thefollowing:a) issues which users wouldn't see, such as code cleanup tasks
b) bug fixes also applied to 10.1.3.1I would like your advice:A) Overall, does this sound like a reasonable approach?
It does to me.
B) Are these filters the right ones or should I edit them?
Am assuming that your filter would not pick Documentation JIRA's - I
don't think Doc JIRA fixes should be exposed. My 0.02 cents.
C) Any tips about how to make this easier?
Not sure - Usually release notes always end-up being hand-crafted :)
Thanks,-Rick

[jira] Commented: (DERBY-1326) Network server may abandon sessions when Derby system is shutdown and this causes intermittent hangs in the client

2006-09-12 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1326?page=comments#action_12434306 ] 

Francois Orsini commented on DERBY-1326:


Well, we do connect to the Derby engine instance from the network server layer 
so if the embedded Derby engine goes down, we would have to reinstantiate the 
database connections (logic is not there right now if am not mistaken), which 
means some state(s) have to be kept around and some logic has to be added. But 
then, how do you handle incoming request from the client(s), especially if it 
takes some time to recover the database(s)...What is there is a corruption and 
some database cannot be recovered? What if after a reboot of the engine some 
derby properties have affected the behavior and configuration of the recovered 
databases - For instance, some database properties are static, so they won't be 
taken into account until the next reboot, which can also mean that a client 
(user) would no longer be allowed to authenticate if the authentication 
provider was changed before the next reboot - This is true for Strong Password 
Substitute which only works with BUILT-IN or NONE authentication providers 
right now...Hence in this last case, a security mechanism negotiation needs to 
happen between the client and the network server...Another case if that if you 
enable authentication at the engine level but derby instance has not rebooted 
yet, you will then not be able to re-authenticate based on the cached database 
info per DRDA session - Simply because a password may not be cached at all 
since there was no authentication required beforehand and now there is because 
the static property got picked-up by the database in question at the next 
engine/database reboot...The connection with the database would not work and 
the client would probably get confused with some authentication exception where 
he/she was already authenticated before the Derby engine got shutdown...

Were you actually implying some auto database reconnect of the current DRDA 
threads created in the network server once the Derby engine or/and databases 
are brought back up?

 Network server may abandon sessions when Derby system is shutdown and this 
 causes intermittent hangs in the client
 --

 Key: DERBY-1326
 URL: http://issues.apache.org/jira/browse/DERBY-1326
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Reporter: Deepa Remesh
 Assigned To: Knut Anders Hatlen
 Attachments: repro1326.java, resolve_DRDConnThread_conflict.diff, 
 Restart.java, sessionMgmt1.diff, 
 sessionMgmt1_and_nosessionsforclosedthreads.diff, 
 unify_NSImpl_instances.diff, withNewThreadAndNoShutdownOfCurrentSession.diff


 This issue was found when working on DERBY-1219. More details can be found in 
 the comments at http://issues.apache.org/jira/browse/DERBY-1219

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

[jira] Commented: (DERBY-1817) Race condition in network server's thread pool

2006-09-11 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433981 ] 

Francois Orsini commented on DERBY-1817:


1817-3-sync.diff looks good to me Knut. Cheers.

 Race condition in network server's thread pool
 --

 Key: DERBY-1817
 URL: http://issues.apache.org/jira/browse/DERBY-1817
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.2.1.0
Reporter: Knut Anders Hatlen
 Assigned To: Knut Anders Hatlen
 Attachments: 1817-2.diff, 1817-3-sync.diff, 1817-4-cleanup.diff, 
 1817-4-cleanup.stat, 1817.diff, 1817.stat


 If there is a free DRDAConnThread when a client connects to the network 
 server, the session is put into a queue from which one of the free 
 DRDAConnThreads can pick it up. However, if another client connects after the 
 session was put into the queue, but before the DRDAConnThread has picked it 
 up, one might end up with more sessions in the queue than there are free 
 threads. This can lead to hangs like the ones that we currently see in many 
 of Ole's tests (for instance checkDataSource - 
 http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/440518-derbyall_diff.txt).

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

[jira] Commented: (DERBY-1817) Race condition in network server's thread pool

2006-09-09 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433581 ] 

Francois Orsini commented on DERBY-1817:


Great changes Knut.

My only comment thus far:

- I think there is a tiny and potential race condition upon retrieving the 
maximum number of threads to create in the network server (via getMaxThreads()) 
and adding a newly created one on the thread list. Not sure if this is possible 
if there is some some higher-level lock but it seems like 'max' could be reset 
while holding the runQueue lock (as we're synchronizing on 2 different objects) 
- It seems like the number of maxThreads can be updated at runtime (see 
processCommands()) - just raising this issue for now - maybe something to 
investigate if you haven't done so already. Just from a quick review.

Cheers.

 Race condition in network server's thread pool
 --

 Key: DERBY-1817
 URL: http://issues.apache.org/jira/browse/DERBY-1817
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.2.1.0
Reporter: Knut Anders Hatlen
 Assigned To: Knut Anders Hatlen
 Attachments: 1817.diff, 1817.stat


 If there is a free DRDAConnThread when a client connects to the network 
 server, the session is put into a queue from which one of the free 
 DRDAConnThreads can pick it up. However, if another client connects after the 
 session was put into the queue, but before the DRDAConnThread has picked it 
 up, one might end up with more sessions in the queue than there are free 
 threads. This can lead to hangs like the ones that we currently see in many 
 of Ole's tests (for instance checkDataSource - 
 http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/440518-derbyall_diff.txt).

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

[jira] Commented: (DERBY-1817) Race condition in network server's thread pool

2006-09-09 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1817?page=comments#action_12433636 ] 

Francois Orsini commented on DERBY-1817:


   It is true that maxThreads could potentially change after it has been 
copied into max and before the new thread is added to the thread list.

This is what I meant Yes.

   I don't think this is a problem since we could end up with more threads 
than maxThreads regardless of synchronization
   (for instance by setting maxThreads to 3 when there are five threads). 
However, I don't see that expanding the synchronization should cause
   any problems either, so I will update my patch. 

Great.

   Thank you very much for looking at the patch!

My pleasure Knut ;)

 Race condition in network server's thread pool
 --

 Key: DERBY-1817
 URL: http://issues.apache.org/jira/browse/DERBY-1817
 Project: Derby
  Issue Type: Bug
  Components: Network Server
Affects Versions: 10.2.1.0
Reporter: Knut Anders Hatlen
 Assigned To: Knut Anders Hatlen
 Attachments: 1817-2.diff, 1817.diff, 1817.stat


 If there is a free DRDAConnThread when a client connects to the network 
 server, the session is put into a queue from which one of the free 
 DRDAConnThreads can pick it up. However, if another client connects after the 
 session was put into the queue, but before the DRDAConnThread has picked it 
 up, one might end up with more sessions in the queue than there are free 
 threads. This can lead to hangs like the ones that we currently see in many 
 of Ole's tests (for instance checkDataSource - 
 http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/440518-derbyall_diff.txt).

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

Re: [jira] Updated: (DERBY-1675) Network Server should not send to client that it supports EUSRIDPWD when running against Sun JVM

2006-09-08 Thread Francois Orsini

Am going to post the few comments I have this afternoon.On 9/8/06, Mike Matrigali (JIRA) derby-dev@db.apache.org
 wrote: [ 
http://issues.apache.org/jira/browse/DERBY-1675?page=all ]Mike Matrigali updated DERBY-1675:--francois
do you have any initial comments on the change?tests passed
for me and they look reasonable but would prefer to get review of
someone experienced in this code.I can work on committing
this today or tommorow, but after that I will be away for a
week.This seems like something that would be nice to get
into 10.2. Network Server should not send to client that it supports EUSRIDPWD when running against Sun JVM 
 Key: DERBY-1675
URL: http://issues.apache.org/jira/browse/DERBY-1675 Project: DerbyIssue Type: ImprovementComponents: Network Server
Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1
, 10.0.2.0, 10.2.1.0Reporter: Sunitha Kambhampati Assigned To: Sunitha KambhampatiPriority: Minor
 Attachments: derby1675.diff.txt, derby1675.stat.txt
As part of ACCSECRD, if the server does not accept the security
mechanism sent by the client,the server will send a list of
security mechanism that it supports. Currently even when the server is
running with sun jvm,it will still send EUSRIDPWD as a sec
mec that it supports, which is incorrect. The server should test if it
can support EUSRIDPWD dynamicallyand if it does, only then
send EURRIDPWD as an option that it supports. see DRDAConnThread.writeACCSECRD(int)--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

[jira] Commented: (DERBY-1675) Network Server should not send to client that it supports EUSRIDPWD when running against Sun JVM

2006-09-08 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1675?page=comments#action_12433535 ] 

Francois Orsini commented on DERBY-1675:


Here are my comments.

Very good changes indeed Sunitha. My comments are ONLY minor ones. Mostly 
recommendations with some of the comments, etc.

1) java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java

A) Static block:

+// Sun JCE does not have support for EUSRIDPWD, whereas
+// most versions of IBM JCE have support for this.  Hence
+// find out if the server can support EUSRIDPWD.

Minor nit but EUSRIDPWD is not part of the JVM - It is just that some JCE 
provider(s) may not have DH support with a Prime of 32-bytes. I 

would have phrased this differently, such as:

// DRDA Specification for the EUSRIDPWD security mechanism
// requires DH algorithm support with a 32-byte prime to be
// used. Not all JCE implementations have support for this.
// Hence here we need to find out if EUSRIDPWD can be used
// with the current JVM.

Again, this is just my recommendation to phrase this differently - Take it or 
leave it :)

+/**
+ * EUSRIDPWD support depends on the availability of the
+ * algorithm in the JCE implementation in the classpath 
+ * of the server. At runtime, information about this 
+ * capability is figured out.  
+ * @return whether EUSRIDPWD is supported or not
+ */

B) supportsEUSRIDPWD():

Here I would have just put the following comments:

/**
 * This method returns whether EUSRIDPWD security mechanism
 * is supported or not. See class static block for more
 * info.
 * @return true if EUSRIDPWD is supported, falso otherwise
 */

I think you need 1 more CR (line space before the next getIntPropVal())

2) +++ 
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/protocol.tests

-readScalar2Bytes SECMEC 3// SECMEC
-readScalar2Bytes SECMEC 9// SECMEC
-readScalar2Bytes SECMEC 4// SECMEC
-readScalar2Bytes SECMEC 8// SECMEC
-readScalar1Byte SECCHKCD 1// SECMEC
+readSecMecAndSECCHKCD // read secmec values and secchkcd

We're loosing the returned list to check here but I guess it is not obvious to 
have this protocol test driver behave conditionally based on the JVM being run, 
etc...since there is no canon's for this test if am not mistaken...Anyway, too 
much of a big deal I'd say.

I have also tested the patch with Solaris / jdk 1.5 ...

Cheers.

 Network Server should not send to client that it supports EUSRIDPWD when 
 running against Sun JVM
 

 Key: DERBY-1675
 URL: http://issues.apache.org/jira/browse/DERBY-1675
 Project: Derby
  Issue Type: Improvement
  Components: Network Server
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.0, 10.1.2.1, 
 10.1.3.0, 10.1.3.1
Reporter: Sunitha Kambhampati
 Assigned To: Sunitha Kambhampati
Priority: Minor
 Attachments: derby1675.diff.txt, derby1675.stat.txt


 As part of ACCSECRD, if the server does not accept the security mechanism 
 sent by the client,  the server will send a list of security mechanism that 
 it supports. Currently even when the server is running with sun jvm,  it will 
 still send EUSRIDPWD as a sec mec that it supports, which is incorrect. The 
 server should test if it can support EUSRIDPWD dynamically  and if it does, 
 only then send EURRIDPWD as an option that it supports.
 see DRDAConnThread.writeACCSECRD(int)

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

[jira] Commented: (DERBY-1675) Network Server should not send to client that it supports EUSRIDPWD when running against Sun JVM

2006-09-08 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-1675?page=comments#action_12433539 ] 

Francois Orsini commented on DERBY-1675:


Oops - Yes this is right - I actually checked the canon's - nevermind Sunitha :)

Thanks.

 Network Server should not send to client that it supports EUSRIDPWD when 
 running against Sun JVM
 

 Key: DERBY-1675
 URL: http://issues.apache.org/jira/browse/DERBY-1675
 Project: Derby
  Issue Type: Improvement
  Components: Network Server
Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.0, 10.1.2.1, 
 10.1.3.0, 10.1.3.1
Reporter: Sunitha Kambhampati
 Assigned To: Sunitha Kambhampati
Priority: Minor
 Attachments: derby1675.diff.txt, derby1675.stat.txt


 As part of ACCSECRD, if the server does not accept the security mechanism 
 sent by the client,  the server will send a list of security mechanism that 
 it supports. Currently even when the server is running with sun jvm,  it will 
 still send EUSRIDPWD as a sec mec that it supports, which is incorrect. The 
 server should test if it can support EUSRIDPWD dynamically  and if it does, 
 only then send EURRIDPWD as an option that it supports.
 see DRDAConnThread.writeACCSECRD(int)

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

[jira] Created: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

2006-09-06 Thread Francois Orsini (JIRA)

Derby Developer's Guide -  Issues w/ User authentication and authorization 
extended examples section/paragraph
--

 Key: DERBY-1823
 URL: http://issues.apache.org/jira/browse/DERBY-1823
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.1.1.0
Reporter: Francois Orsini
Priority: Minor


There is a couple of issues with the paragraph/section  User authentication 
and authorization extended examples in the developer's guide
http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html

1) The methods turnOnBuiltInUsers()  turnOffBuiltInUsers() do NOT shutdown and 
reboot the database for which the 'derby.connection.requireAuthentication' 
authentication database property is being set - as this last one is a derby 
static property, it will not be taken into account until the database is 
rebooted (or the whole derby engine instance). Hence, the 2 checks for 
Confirming requireAuthentication is misleading as the property value is 
changed _but_ the actual database authentication enabling/disabling has not 
changed since it was last booted. Database needs to be shutdown and rebooted 
after 'derby.connection.requireAuthentication' is set and then some negative 
testing of invalid user connection needs to be added to show that only valid 
users can connect (in the case, authentication is being enabled).

2) Paragraph (extended examples section) also needs to be moved at the same 
level as the 2 above such as:
  User authentication example in a single-user, embedded environment
  http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
  User authentication example in a client/server environment
  http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html

since the extended examples (once fixed - see 1)) can be applied in both a 
client-server and embedded environments context.


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

[jira] Closed: (DERBY-1711) In an embedded env, connection happens properly even when the password supplied is wrong.

2006-09-06 Thread Francois Orsini (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-1711?page=all ]

Francois Orsini closed DERBY-1711.
--

Resolution: Invalid

Closing as this is not a bug. Thanks Rajesh for producing the sample script.

I have create DERBY-1823 for the documentation issue, in respect with shutting 
down and rebooting the database in the  provided extended samples where 
'derby.connection.requireAuthentication'  is being (re)set.

 In an embedded env, connection happens properly even when the password 
 supplied is wrong.
 -

 Key: DERBY-1711
 URL: http://issues.apache.org/jira/browse/DERBY-1711
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.1.3.1
 Environment: Win XP,Java 1.4.x
Reporter: Chinmay Bajikar
 Attachments: 1171.sql, derby.zip


 Hi,
 I am a new user of Derby.
 Have tried to set user authorization at the database level using the example 
 given in the Derby Dev Guide.(Page 85).
 The steps that I do are as follows,
 1)Create a db (using create=true attribute in the connection url)
 2) Connect to the db and set the appropriate properties i.e. set 
 requireAuthentication to true,provider to builtin, add a new user,passwrd and 
 give it full access.
 3) Set the default access level to noAccess.
 4) Close this connection.
 5) Now make a new connection using the user name/passwd.It connects fine.
 6) Now try to make a new connection using a wrong user name and it gives a 
 Connection Refused exception.
 7) Finally try giving a right username and wrong passwd and the connection 
 still happens.
 Have attached the source file which does all these above steps for 
 reproducing the issue.
 Thanks,
 Chinmay.

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

[jira] Commented: (DERBY-1740) Change error message to indicate encryptionkey length to be atleast 16 characters instead of 8 characters

[
http://issues.apache.org/jira/browse/DERBY-1740?page=comments#action_12432109 ]

Francois Orsini commented on DERBY-1740:

It seems the concepts of 'bootPassword' and 'encryptionKey' are pretty much
unrelated [in Derby].
If you create the database with a boot password, you must always boot the
database with a boot password.
You cannot specify a corresponding encryption key to boot it. The same
goes for encryptionKey, you cannot
boot it using a corresponding boot password.
Is my understanding correct?

That is correct Kristian. You use either one of them but not both at the same
time - as well as you can't use some encryption key generated out of a
bootPassword as it is not made available (not known).

Further, it seems code handling these two concepts are co-located in the
same classes/methods,
and often a single error message is used for error-situations for both
concepts.
For instance, if I create an encrypted database using the encryptionKey
attribute and try to boot it using
an incorrect encryptionKey, or by using the bootPassword attribute, I get:
ERROR XBM06: Startup failed. An encrypted database cannot be accessed
without the correct boot password.
Also, specifying both attributes gives the same exception/SQLState as above.

Correct - This is what the code does at the moment.

Thus it seems this Jira is only one of several related
problems/inaccuracies related to
creating/booting encrypted databases.
Can anyone with more knowledge comment on this?

Yes, error messaging has to be improved for some of the various scenarios you
already came accross...

The bootPassword must be of at least 8 bytes as the default cipher algorithm is
DES (56 bits)...The external encryption key (when specified instead of the
bootPassword) should be of a particular length (Hex string) depending on the
cipher algorithm being specified or not (default being DES)...Of course, the
minimum for the external encryption key also has to be of 16 bytes (8x2) (with
a default cipher as DES).

Your patch looks good IMO. I would re-phrase the error message into something
like:
XBCXM.S.1=The length of the external encryption key is {0}, it should be of at
least {1}.

Yes it is ok to use bytes for the bootPassword and hex string length for the
(external) encryption key as a the units.

Hope this helps a bit. There are some improvements that can be done in this
area of code - certainly some refactoring as well as better handling of
encryption key length, determining weak and semi-weak keys (other than just for
DES - e.g. 3DES) ) for the various supported crypto cipher algorithms wherever
it makes sense...

You should test the patch with the database encryption test suite as well of
course.

Change error message to indicate encryptionkey length to be atleast 16
characters instead of 8 characters
-

Key: DERBY-1740
URL: http://issues.apache.org/jira/browse/DERBY-1740
Project: Derby
Issue Type: Bug
Affects Versions: 10.0.2.0
Environment: Any
Reporter: Rajesh Kartha
Priority: Minor
Fix For: 10.2.1.0

Attachments: derby-1740-1a.diff

While attempting to create a encrypted database with even key length of 14
characters, it fails with the error message indicating the key length should
be atleast 8 characters.
--
-- Attempt to encrypt using key of lenght 14
--
ij connect
'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=11223344556677';
ERROR XJ041: Failed to create database 'adb', see the next exception for
details.
ERROR XBM01: Startup failed due to an exception. See next exception for
details.
ERROR XBCX2: Initializing cipher with a boot password that is too short. The
password must be at least 8 characters long.
--
--Requires 16 characters for the encryptionKey
--
ij connect
'jdbc:derby:adb;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=1122334455667788';
ij

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

[jira] Commented: (DERBY-1788) Using secmec 8(USRSSSBPWD) on 141 vms, fails with java.security.NoSuchAlgorithmException : SHA1PRNG.

[ 
http://issues.apache.org/jira/browse/DERBY-1788?page=comments#action_12432124 ] 

Francois Orsini commented on DERBY-1788:


Hi Sunitha - I'm assuming that the 141 JVM being tested was the IBM one...

Effectively, under (e.g. 1.3.x) and up to that JVM version level, the random 
number generator supplied by the IBMJCE provider was 'SHA1PRNG' - It then got 
removed as part of IBM Crypto provider 1.4.1  and  'IBMSecureRandom' was made 
available solely.

But it then appears that 'SHA1PRNG' made it back to the IBM Crypto provider as 
part of 1.4.2 and forward - which is what I tested with...

I believe this could be documented as part of the secmec comments columns in 
the developer's guide...

It would still be possible to fix eventhough the IBMSecureRandom's 
implementation uses a MD5 message digest which obviously will produce a 
different output that some SHA computed one, but that is fine as the generator 
in this context is used to generate a random number (seed) which got exchanged 
on both sides (client and server) - It is 8 bytes and even if the client used a 
different genertor than the server, it will be fine - So what could be done is 
to catch the SHA1PRNG NoSuchAlgorithmException exception (happening under IBM 
JVM 1.4.1) and then in the catch block try and new some 'IBMSecureRandom' 
generator which would then succeed... :-)



 Using secmec 8(USRSSSBPWD) on 141 vms, fails with 
 java.security.NoSuchAlgorithmException : SHA1PRNG.
 

 Key: DERBY-1788
 URL: http://issues.apache.org/jira/browse/DERBY-1788
 Project: Derby
  Issue Type: Bug
  Components: Network Server, Network Client
Affects Versions: 10.2.1.0
Reporter: Sunitha Kambhampati
Priority: Minor

 I ran  the testSecMec test with client  141 vm and hit this error.
 This could probably  be a documentation issue --  that we document what level 
 of algorithm support is required for secmec 8 
 T9: 
 jdbc:derby://localhost:2/wombat;user=neelima;password=lee;securityMechanism=8
  - EXCEPTION Security exception encountered, see next exception for details.
 java.sql.SQLException: Security exception encountered, see next exception for 
 details.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:46)
   at 
 org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:345)
   at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
   at java.sql.DriverManager.getConnection(DriverManager.java:538)
   at java.sql.DriverManager.getConnection(DriverManager.java:210)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.getConnectionUsingDriverManager(testSecMec.java:471)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.runTest(testSecMec.java:383)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec.main(testSecMec.java:260)
 Caused by: org.apache.derby.client.am.SqlException: Security exception 
 encountered, see next exception for details.
   at 
 org.apache.derby.client.am.EncryptionManager.init(EncryptionManager.java:156)
   at 
 org.apache.derby.client.net.NetConnection.initializeClientSeed(NetConnection.java:1426)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(NetConnection.java:721)
   at 
 org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:459)
   at 
 org.apache.derby.client.net.NetConnection.init(NetConnection.java:217)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:201)
   at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:140)
   ... 5 more
 Caused by: java.security.NoSuchAlgorithmException: SHA1PRNG SecureRandom not 
 available
   at java.security.Security.getAlgClassName(Security.java:576)
   at java.security.Security.getAlgClassName(Security.java:598)
   at java.security.Security.getImpl(Security.java:1079)
   at java.security.SecureRandom.getInstance(SecureRandom.java:241)
   at 
 org.apache.derby.client.am.EncryptionManager.init(EncryptionManager.java:148)

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

[jira] Commented: (DERBY-1756) Revert change in client that defaults the secmec to eusridpwd.

[ 
http://issues.apache.org/jira/browse/DERBY-1756?page=comments#action_12432195 ] 

Francois Orsini commented on DERBY-1756:


Looks good Sunitha - Just some minor comment...

In ClientBaseDataSource.java, I think it would be good to leave most of the 
logic around support for EUSRIDPWD checks in the file as this would certainly 
get re-enabled once #1517 and #1755 are fixed...I believe they will still be 
valid, even if some logic is being moved around in some other helper classes 
used during secmec handshake/negotiation . They can be left commented out with 
a comment explaining why (such as mentioning JIRA-1517, JIRA-1755) - as I did 
in my note  for the USRSSBPWD upgrade (commented out as well for now).

My IMPORTANT NOTE on USRSSBPWD upgrade comment is out of context if the 3 lines 
above (shown below) are removed...as we will still try to upgrade to EUSRIDPWD 
if the client supports it when it is re-enabled...

-if (SUPPORTS_EUSRIDPWD)
-return (short)NetConfiguration.SECMEC_EUSRIDPWD;
-else

Just some suggestion...meanwhile #1517 and #1755 are addressed

 Revert change in client that defaults the secmec to eusridpwd.
 --

 Key: DERBY-1756
 URL: http://issues.apache.org/jira/browse/DERBY-1756
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.2.1.0
Reporter: Sunitha Kambhampati
 Assigned To: Sunitha Kambhampati
 Fix For: 10.2.1.0

 Attachments: derby1756.diff.txt, derby1756.stat.txt


 With changes to derby-962, the client would default to eusridpwd if the 
 client jvm supports it.  It is not sufficient to only check if client jvm can 
 support eusridpwd  but we need to verify if the server can support the 
 particular secmec.  
 There are other existing jiras DERBY-1675,DERBY-1517,DERBY-1755 that will 
 help to address the issue of  upgrading to a better security mechanism.
 This jira will change the default security mechanism to 3 as it was before 
 derby-962 changes.

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

[jira] Commented: (DERBY-1756) Revert change in client that defaults the secmec to eusridpwd.

[ 
http://issues.apache.org/jira/browse/DERBY-1756?page=comments#action_12432210 ] 

Francois Orsini commented on DERBY-1756:


Looks good - Thanks Sunitha.

+1

 Revert change in client that defaults the secmec to eusridpwd.
 --

 Key: DERBY-1756
 URL: http://issues.apache.org/jira/browse/DERBY-1756
 Project: Derby
  Issue Type: Bug
  Components: Network Client
Affects Versions: 10.2.1.0
Reporter: Sunitha Kambhampati
 Assigned To: Sunitha Kambhampati
 Fix For: 10.2.1.0

 Attachments: Derby1756.2.diff.txt, derby1756.diff.txt, 
 derby1756.stat.txt


 With changes to derby-962, the client would default to eusridpwd if the 
 client jvm supports it.  It is not sufficient to only check if client jvm can 
 support eusridpwd  but we need to verify if the server can support the 
 particular secmec.  
 There are other existing jiras DERBY-1675,DERBY-1517,DERBY-1755 that will 
 help to address the issue of  upgrading to a better security mechanism.
 This jira will change the default security mechanism to 3 as it was before 
 derby-962 changes.

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

Re: [jira] Closed: (DERBY-1695) testSecMec.java fails with JCC 2.6 and JCC 2.8

2006-08-29 Thread Francois Orsini

Thanks for running the tests and updating the canon files Sunitha.On 8/29/06, Sunitha Kambhampati (JIRA) derby-dev@db.apache.org
 wrote: [ 
http://issues.apache.org/jira/browse/DERBY-1695?page=all ]Sunitha Kambhampati closed DERBY-1695.--Resolution: FixedVerified that the test passes now. with 
jcc2.6 and jcc2.8, so closing this issue. testSecMec.java fails with JCC 2.6 and JCC 2.8 -- Key: DERBY-1695
URL: http://issues.apache.org/jira/browse/DERBY-1695 Project: DerbyIssue Type: TestComponents: Test, Regression Test Failure
Affects Versions: 10.2.1.0Reporter: Kathey Marsden Assigned To: Sunitha KambhampatiPriority: Minor Fix For: 
10.2.1.0, 10.3.0.0 Attachments: derby1695.diff.txt, Derby1695.stat.txt
After the checkin for DERBY-528 testSecMec fails with JCC 2.6 and
2.8.My hope was to just wait until the masters were
normalized with the conversion of this test to Junit, but I think that
work has been deferred for a bit so I will look at the current test.
I have had a problem with this test on my machine for sometime with
DERBY-1114 like symptoms with all jvms and even with
derbyclient.I need to investigate that or run on another
machine to resolve this issue.--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

[jira] Commented: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature

[ 
http://issues.apache.org/jira/browse/DERBY-1747?page=comments#action_12430059 ] 

Francois Orsini commented on DERBY-1747:


Many thanks Kim - Much appreciated.

1) The 
org.apache.derby.jdbc.ClientDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY 
should have that underscore - absolutely - It is not something I changed but 
it'd be nice to fix it as part of these changes nonetheless...

2) I meant e.g. (for example) :-)

3) Yes the space(s) should be closed-up - Had noticed this as well...

Cheers.

 Documentation for 10.2 Strong Password Substitute feature
 -

 Key: DERBY-1747
 URL: http://issues.apache.org/jira/browse/DERBY-1747
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Francois Orsini
 Assigned To: Kim Haase
 Fix For: 10.2.2.0

 Attachments: cadminapps49914.html, cadminapps49914.html.diffs, 
 cadminappsclientsecurity.html, cadminappsclientsecurity.html.diffs, 
 tdevcsecure82556.html, tdevcsecure82556.html.diffs


 I have attached some documentation additions for DERBY-528 (Strong Password 
 Substitute).
 Thanks in advance for any comments.
 Admin Guide:
 --
  - cadminapps49914.html
  - cadminappsclientsecurity.html
 Developer Guide:
 --
  - tdevcsecure82556.html
 Diffs for the HTML posted as well for each of these 3 files.
 Am not expert at DITA and the whole process of updating documentation, if 
 someone could help with updating these (small) additions to the documentation 
 trunk I would appreciate - am going through the process of editing 
 documentation as of now...Thanks in advance.

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

Re: [jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers

2006-08-24 Thread Francois Orsini

On 8/23/06, Sunitha Kambhampati [EMAIL PROTECTED]
 wrote:
Hi Francois, Thanks for taking this task on.Francois Orsini (JIRA) wrote:snipYou're
right that there is no longer an issue with a DERBY-528 and a 10.2
client connecting to a 10.1 derby server, I reverted back to
havingCLEAR_TEXT_PASSWORD being the default SECMEC to use
on client datasource (if EUSRIDPWD cannot be selected because of the
current JVM restricting the use of 256-bit DH keys).Without
DERBY-1517, a DRDA protocol exception will be raised if an invalid
securityMechanism is specified for the server the client connects to -
This was a fairly non-blocking and non-visible issue since all
pre-DERBY-528 DRDA secmec were supported by pretty much all existing
Derby DRDA servers out there. Eventhough DERBY-926 needs to be
addressed, DERBY-1517 will allow a new DRDA secmec (like USRSSBPWD) to
be used as a fall-back default when EUSRIDPWD cannot be used,It seems to me we need some amount of negotiation between the server andclient on the security mechanism to use.(correct?)


That is correct - This is what I have been implementing/testing thus far.
E.g. For having secmec 8 to be used by default by the 10.2 client, theold server will not recognize this and will currently send a list of
supported secmecs (in the wrong format -derby926).Changes will beneeded in the client to parse these values and then choose one of thesecmec's that is valid for the server. Were you planning on making
these changes so secmec 8 can be used as the fallback default or did you
have some other approach in mind. Are you targeting this for 10.2.
Originally as I had implemented and tested it as part of derby-528,
secmec 8 was the second best default after secmec 9 (32-byte DH key
support required) - Now with the new negotiation logic, if the
target server cannot support secmec 8, I would have picked secmec 3.
Yes, am targeting this for 10.2 - am just doing testing and fixing
right now...
 I also noticed a problem in the client, using the default to secmec 9.I think it is not sufficient to only check if client jvm can support
eusridpwd as is done currently (derby-962) but we need to verify if theserver can support the particular secmec.At the very least, to avoidregressing, we should revert back to secmec 3. I'll open a jira to fix
this. I'll link all these related jiras (derby-1675,derby-926)
Yep, this is a valid one as well...and I think we should address it for
10.2. Well, with the client/server negotiation in-place, we should be
able to handle that one as well - the only additional (logic) work is
to check if secmec 9 can be used on the server and as far as I know,
this logic needs to be implemented - would be good to fix all these
issues...
Also,
the sooner we fix DERBY-926, the better it is for no longer carrying
servers that are returning the list of supported secmec's incorrectly.
+1.Thanks,Sunitha.

Re: Upcoming 10.2 candidates

2006-08-24 Thread Francois Orsini

I reviewed the content (generated HTML in the diffs) and it looks good... +1

Would appreciate a commit if there is no further comment(s)

Thanks,

--francoisOn 8/24/06, Jean T. Anderson [EMAIL PROTECTED] wrote:
Rick Hillegas wrote: DERBY-1747 - Kim needs some more feedback from Francois before these changes can commit. Unfortunately, Francois is on vacation for the rest of this week.Does this just need a final review? I see that Kim posted an updated
patch + zip with html for review. If anyone else is knowledgeable enoughin this area to review it, feel free to do so and I'll watch for a noteindicating it's ready to commit.also ... jira notices do seem to be log jammed again today. So if
anything is newly ready to review or ready to commit please post. -jean

Re: Upcoming 10.2 candidates

2006-08-24 Thread Francois Orsini

On 8/24/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Thanks Rajesh. Are you recommending that I not build a new beta untilthese documentation changes commit?DERBY-1636 - Suresh has a remaining issue with these documentationchanges. I don't know when these changes will settle down.
DERBY-1655 - According to the last comment on this issue, thesedocumentation changes committed. What more needs to be done here?DERBY-1747 - Kim needs some more feedback from Francois before thesechanges can commit. Unfortunately, Francois is on vacation for the rest
of this week.
Fortunately, I posted my feeback in the JIRA. +1.
Regards,-RickRajesh Kartha wrote:
 1) Instead of a release candidate, I could build a new beta candidate tomorrow (Friday August 25). I would think a new beta candidate will be useful to the community for testing given the mega-merge of changes from trunk to 
10.2 branch since the last beta and that the official release candidate is expected on a later date It would also be desirable if the documentation of the newer feature (for example: DERBY-1636, DERBY-1655, DERBY-1747) were also
 available by this beta refresh. -Rajesh

Re: Upcoming 10.2 candidates

2006-08-24 Thread Francois Orsini

Thanks Jean - Well at least my 4h wait at the airport will not have been completely wasted :) - Cheers.On 8/24/06, Jean T. Anderson 
[EMAIL PROTECTED] wrote:Francois Orsini wrote: I reviewed the content (generated HTML in the diffs) and it looks
 good... +1 Would appreciate a commit if there is no further comment(s)thanks, Francois, I'll commit -- and have a great vacation for whateveris left of this week! -jean

[jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[ 
http://issues.apache.org/jira/browse/DERBY-528?page=comments#action_12430331 ] 

Francois Orsini commented on DERBY-528:
---

DERBY-1747 is the documentation JIRA for this feature.

 Support for DRDA Strong User ID and Password Substitute Authentication 
 (USRSSBPWD) scheme
 -

 Key: DERBY-528
 URL: http://issues.apache.org/jira/browse/DERBY-528
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.1.1.0
Reporter: Francois Orsini
 Assigned To: Francois Orsini
 Fix For: 10.2.1.0

 Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 528_diff_v3.txt, 
 528_diff_v4.txt, 528_diff_v5.txt, 528_SecMec_Testing_Table.txt, 
 528_stat_v1.txt, 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.txt, 
 528_stat_v5.txt


 This JIRA will add support for (DRDA) Strong User ID and Password Substitute 
 Authentication (USRSSBPWD) scheme in the network client/server driver layers.
 Current Derby DRDA network client  driver supports encrypted userid/password 
 (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open 
 Group DRDA specifications imposes small prime and base generator values (256 
 bits) that prevents other JCE's  to be used as java cryptography providers - 
 typical minimum security requirements is usually of 1024 bits (512-bit 
 absolute minimum) when using DH key-agreement protocol to generate a session 
 key.
 Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of 
 DRDA specifications as another alternative to provide ciphered passwords 
 across the wire.
 Support of USRSSBPWD authentication scheme will enable additional JCE's to  
 be used when encrypted passwords are required across the wire.
 USRSSBPWD authentication scheme will be specified by a Derby network client 
 user via the securityMechanism property on the connection UR - A new property 
 value such as ENCRYPTED_PASSWORD_SECURITY will be defined in order to support 
 this new (DRDA) authentication scheme.

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

[jira] Commented: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature

[ 
http://issues.apache.org/jira/browse/DERBY-1747?page=comments#action_12430329 ] 

Francois Orsini commented on DERBY-1747:


Thanks you so much Kim. It would be good to commit this documentation - Am 
working on expanded documentation for Derby network security but am waiting for 
some changes am making (DERBY-1517) before publishing it...So this first set 
can be committed in the meantime to reflect the current state...Cheers.

 Documentation for 10.2 Strong Password Substitute feature
 -

 Key: DERBY-1747
 URL: http://issues.apache.org/jira/browse/DERBY-1747
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Francois Orsini
 Assigned To: Kim Haase
 Fix For: 10.3.0.0

 Attachments: cadminapps49914.html, cadminapps49914.html.diffs, 
 cadminappsclientsecurity.html, cadminappsclientsecurity.html.diffs, 
 DERBY-1747.diff, DERBY-1747.zip, tdevcsecure82556.html, 
 tdevcsecure82556.html.diffs


 I have attached some documentation additions for DERBY-528 (Strong Password 
 Substitute).
 Thanks in advance for any comments.
 Admin Guide:
 --
  - cadminapps49914.html
  - cadminappsclientsecurity.html
 Developer Guide:
 --
  - tdevcsecure82556.html
 Diffs for the HTML posted as well for each of these 3 files.
 Am not expert at DITA and the whole process of updating documentation, if 
 someone could help with updating these (small) additions to the documentation 
 trunk I would appreciate - am going through the process of editing 
 documentation as of now...Thanks in advance.

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

[jira] Commented: (DERBY-1682) Add documentation for derby.drda.securityMechanism.

[
http://issues.apache.org/jira/browse/DERBY-1682?page=comments#action_12430333 ]

Francois Orsini commented on DERBY-1682:

Hi Kim,

Yes, STRONG_PASSWORD_SUBSTITUTE_SECURITY should be added to the list and as
part of the 3 other already listed...

Thanks and good catch.

--francois

Add documentation for derby.drda.securityMechanism.
---

Key: DERBY-1682
URL: http://issues.apache.org/jira/browse/DERBY-1682
Project: Derby
Issue Type: Task
Components: Documentation
Reporter: Sunitha Kambhampati
Assigned To: Laura Stewart
Priority: Minor
Fix For: 10.3.0.0

Attachments: derby1682_adminguide.diff, radmindrdasecmechanism.html

Under section Setting Network Server properties
http://db.apache.org/derby/docs/dev/adminguide/tadminconfigsettingnetwrokserverproperties.html
Add this new property
derby.drda.securityMechanism
Restricts client connections based on the security mechanism.
if derby.drda.securityMechanism is set to a valid mechanism, then
the Network Server accepts only connections which use that
security mechanism. No other types of connections are accepted.
if the derby.drda.securityMechanism is not set at all, then the
Network Server accepts any connection which uses a valid
security mechanism.
Syntax:
derby.drda.securityMechanism=[USER_ONLY_SECURITY|CLEAR_TEXT_PASSWORD_SECURITY|ENCRYPTED_USER_AND_PASSWORD_SECURITY]
Example:
derby.drda.securityMechanism=USER_ONLY_SECURITY
The server running with this property will only accept client connections
with USER_ONLY_SECURITY.
Static or Dynamic:
This property is static. Server must be restarted for the property to take
effect.
Default value for this property is as though it is not set - in which case
the server will allow clients with supported security mechanisms to connect

Re: Jira mails not coming through ?

2006-08-23 Thread Francois Orsini

I received several JIRA notifications after 9.55 am pst - However what
you're experiencing has already happening to me before and I never got
to see the notifications - It might just be some isolated issue
though...On 8/23/06, Sunitha Kambhampati [EMAIL PROTECTED] wrote:
I have not received any jira mails from morning ( last one I got was at9.55 am pst) .I looked at some jira entries and I see updates/comments etc but none of them made it to my inbox. Is this somethingonly I am seeing or is the server slow ?
Thanks,Sunitha.

[jira] Commented: (DERBY-1711) In an embedded env, connection happens properly even when the password supplied is wrong.

[ 
http://issues.apache.org/jira/browse/DERBY-1711?page=comments#action_12429746 ] 

Francois Orsini commented on DERBY-1711:


Hi Chinmay,

This is not a bug - The 'derby.connection.requireAuthentication' derby property 
is a static one - Once it is set to true to turn on authentication, the 
database or derby instance needs to be re-booted - So, if you set this property 
to true at the database level, just shutdown the database and re-open a 
connection to that database for the property to be taken into account during 
the following database boot...

However, the example in the guide does NOT do some proper testing in my opinion 
- it basically checks if the properties have been set but it does NOT 
intrinsically check if authentication has really been turned by doing more 
negative testing...The example also does NOT shutdown and restart the database 
for the derby static properties to be taken into acount. This bug should be 
converted into a documentation one - I also believe that we need to highlight 
more the fact that the 'derby.connection.requireAuthentication' property is a 
static one...

Hope this helps - in the meantime...

 In an embedded env, connection happens properly even when the password 
 supplied is wrong.
 -

 Key: DERBY-1711
 URL: http://issues.apache.org/jira/browse/DERBY-1711
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.1.3.1
 Environment: Win XP,Java 1.4.x
Reporter: Chinmay Bajikar
 Attachments: derby.zip


 Hi,
 I am a new user of Derby.
 Have tried to set user authorization at the database level using the example 
 given in the Derby Dev Guide.(Page 85).
 The steps that I do are as follows,
 1)Create a db (using create=true attribute in the connection url)
 2) Connect to the db and set the appropriate properties i.e. set 
 requireAuthentication to true,provider to builtin, add a new user,passwrd and 
 give it full access.
 3) Set the default access level to noAccess.
 4) Close this connection.
 5) Now make a new connection using the user name/passwd.It connects fine.
 6) Now try to make a new connection using a wrong user name and it gives a 
 Connection Refused exception.
 7) Finally try giving a right username and wrong passwd and the connection 
 still happens.
 Have attached the source file which does all these above steps for 
 reproducing the issue.
 Thanks,
 Chinmay.

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

[jira] Updated: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature

 [ http://issues.apache.org/jira/browse/DERBY-1747?page=all ]

Francois Orsini updated DERBY-1747:
---

Fix Version/s: 10.2.2.0
   (was: 10.0.2.2)
Affects Version/s: 10.2.1.0
   (was: 10.0.2.0)

 Documentation for 10.2 Strong Password Substitute feature
 -

 Key: DERBY-1747
 URL: http://issues.apache.org/jira/browse/DERBY-1747
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Francois Orsini
 Fix For: 10.2.2.0

 Attachments: cadminapps49914.html, cadminapps49914.html.diffs, 
 cadminappsclientsecurity.html, cadminappsclientsecurity.html.diffs, 
 tdevcsecure82556.html, tdevcsecure82556.html.diffs


 I have attached some documentation additions for DERBY-528 (Strong Password 
 Substitute).
 Thanks in advance for any comments.
 Admin Guide:
 --
  - cadminapps49914.html
  - cadminappsclientsecurity.html
 Developer Guide:
 --
  - tdevcsecure82556.html
 Diffs for the HTML posted as well for each of these 3 files.
 Am not expert at DITA and the whole process of updating documentation, if 
 someone could help with updating these (small) additions to the documentation 
 trunk I would appreciate - am going through the process of editing 
 documentation as of now...Thanks in advance.

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

[jira] Updated: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature

 [ http://issues.apache.org/jira/browse/DERBY-1747?page=all ]

Francois Orsini updated DERBY-1747:
---

Attachment: cadminapps49914.html.diffs
cadminappsclientsecurity.html.diffs
tdevcsecure82556.html.diffs

attaching diffs this time.

 Documentation for 10.2 Strong Password Substitute feature
 -

 Key: DERBY-1747
 URL: http://issues.apache.org/jira/browse/DERBY-1747
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Francois Orsini
 Fix For: 10.2.2.0

 Attachments: cadminapps49914.html, cadminapps49914.html.diffs, 
 cadminappsclientsecurity.html, cadminappsclientsecurity.html.diffs, 
 tdevcsecure82556.html, tdevcsecure82556.html.diffs


 I have attached some documentation additions for DERBY-528 (Strong Password 
 Substitute).
 Thanks in advance for any comments.
 Admin Guide:
 --
  - cadminapps49914.html
  - cadminappsclientsecurity.html
 Developer Guide:
 --
  - tdevcsecure82556.html
 Diffs for the HTML posted as well for each of these 3 files.
 Am not expert at DITA and the whole process of updating documentation, if 
 someone could help with updating these (small) additions to the documentation 
 trunk I would appreciate - am going through the process of editing 
 documentation as of now...Thanks in advance.

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

[jira] Updated: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature

 [ http://issues.apache.org/jira/browse/DERBY-1747?page=all ]

Francois Orsini updated DERBY-1747:
---

Attachment: cadminapps49914.html
cadminappsclientsecurity.html
tdevcsecure82556.html

 Documentation for 10.2 Strong Password Substitute feature
 -

 Key: DERBY-1747
 URL: http://issues.apache.org/jira/browse/DERBY-1747
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.0
Reporter: Francois Orsini
 Fix For: 10.2.2.0

 Attachments: cadminapps49914.html, cadminapps49914.html.diffs, 
 cadminappsclientsecurity.html, cadminappsclientsecurity.html.diffs, 
 tdevcsecure82556.html, tdevcsecure82556.html.diffs


 I have attached some documentation additions for DERBY-528 (Strong Password 
 Substitute).
 Thanks in advance for any comments.
 Admin Guide:
 --
  - cadminapps49914.html
  - cadminappsclientsecurity.html
 Developer Guide:
 --
  - tdevcsecure82556.html
 Diffs for the HTML posted as well for each of these 3 files.
 Am not expert at DITA and the whole process of updating documentation, if 
 someone could help with updating these (small) additions to the documentation 
 trunk I would appreciate - am going through the process of editing 
 documentation as of now...Thanks in advance.

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

[jira] Commented: (DERBY-1747) Documentation for 10.2 Strong Password Substitute feature