date:20120927

[jira] [Resolved] (DERBY-5905) Derby html documentation doesn't render properly and prints garbage on Internet Explorer

2012-09-27 Thread Knut Anders Hatlen (JIRA)

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

Knut Anders Hatlen resolved DERBY-5905.
---

Resolution: Fixed
Fix Version/s: 10.10.0.0
10.9.1.1
10.8.2.3
Assignee: Knut Anders Hatlen

Yes, I think the work on this issue is done. Marking as fixed.

Derby html documentation doesn't render properly and prints garbage on
Internet Explorer

Key: DERBY-5905
URL: https://issues.apache.org/jira/browse/DERBY-5905
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.8.2.2, 10.9.1.0, 10.10.0.0
Reporter: Kathey Marsden
Assignee: Knut Anders Hatlen
Fix For: 10.8.2.3, 10.9.1.1, 10.10.0.0

Attachments: ASF.LICENSE.NOT.GRANTED--screenshot-1.jpg,
d5905-1a-move-comments.diff, d5905-2a-lang-attribute.diff

There have been reports that DERBY html documentation does not render on
Internet Explorer 8 and 9.
Kristian reports on IE8
Just tried with IE8, and with the Getting Started manual I get this when I
view the source:

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
HTMLHEAD
META content=text/html; charset=utf-8 http-equiv=Content-Type/HEAD
BODY/BODY/HTML
snipped garbage as to not put it in jira
Not sure how that last line will turn out in your email clients, but it is
indeed garbage and you can see that the body-tag is empty. Nothing is
rendered in the browser. We are using frames though - that's not exactly
state-of-the-art... We are also using the wrong DOCTYPE. I'm suspecting that
the HTML is invalid too, but haven't checked.
On IE9 I had heard that the reference HTML manual prints garbage.
http://db.apache.org/derby/manuals/index.html#latest

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-672) Re-enable user defined aggregates

2012-09-27 Thread Rick Hillegas (JIRA)


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

Rick Hillegas updated DERBY-672:


Attachment: derby-672-09-ab-udtAggregates.diff

Attaching derby-672-09-ab-udtAggregates.diff. This patch makes it possible to 
create aggregates on user defined types. I am running regression tests now.

Touches the following files:

--

M   java/engine/org/apache/derby/impl/sql/compile/QueryTreeNode.java
M   java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java

The input and return types of the aggregate needed to be bound in order for 
CREATE DERBY AGGREGATE to succeed on user defined types. 

--

M   
java/testing/org/apache/derbyTesting/functionTests/tests/lang/UserDefinedAggregatesTest.java
A   
java/testing/org/apache/derbyTesting/functionTests/tests/lang/FullName.java
M   
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GenericMode.java
M   java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml

Additional test case for creating aggregates on a user-defined type.


 Re-enable user defined aggregates
 -

 Key: DERBY-672
 URL: https://issues.apache.org/jira/browse/DERBY-672
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: derby-672-01-aa-ddl.diff, 
 derby-672-02-ac-nonDistinct.diff, derby-672-03-aa-distinct.diff, 
 derby-672-03-ab-distinct.diff, derby-672-04-aa-fixJSR169test.diff, 
 derby-672-05-aa-java7testOrderProblem.diff, derby-672-06-aa-grantRevoke.diff, 
 derby-672-07-aa-fixJSR169again.diff, derby-672-08-aa-fixJSR169yetAgain.diff, 
 derby-672-09-ab-udtAggregates.diff, UserDefinedAggregates.html, 
 UserDefinedAggregates.html


 Nicolas Dufour in an email thread titled functions and list started on 
 November 2, 2005 requests the ability to create user defined aggregates.
 This functionality used to be in Cloudscape. It was disabled presumably 
 because it was considered non-standard. However, most of the machinery needed 
 for this feature is still in the code. We should re-enable user defined 
 aggregates after we agree on acceptable syntax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-672) Re-enable user defined aggregates

2012-09-27 Thread Knut Anders Hatlen (JIRA)

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

Knut Anders Hatlen commented on DERBY-672:
--

Thanks for eliminating the duplicated code. :) The 09-ab patch looks good to
me. +1.

Re-enable user defined aggregates
-

Key: DERBY-672
URL: https://issues.apache.org/jira/browse/DERBY-672
Project: Derby
Issue Type: Improvement
Components: SQL
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Attachments: derby-672-01-aa-ddl.diff,
derby-672-02-ac-nonDistinct.diff, derby-672-03-aa-distinct.diff,
derby-672-03-ab-distinct.diff, derby-672-04-aa-fixJSR169test.diff,
derby-672-05-aa-java7testOrderProblem.diff, derby-672-06-aa-grantRevoke.diff,
derby-672-07-aa-fixJSR169again.diff, derby-672-08-aa-fixJSR169yetAgain.diff,
derby-672-09-ab-udtAggregates.diff, UserDefinedAggregates.html,
UserDefinedAggregates.html

Nicolas Dufour in an email thread titled functions and list started on
November 2, 2005 requests the ability to create user defined aggregates.
This functionality used to be in Cloudscape. It was disabled presumably
because it was considered non-standard. However, most of the machinery needed
for this feature is still in the code. We should re-enable user defined
aggregates after we agree on acceptable syntax.

[jira] [Commented] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2

2012-09-27 Thread Bryan Pendleton (JIRA)

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

Bryan Pendleton commented on DERBY-2130:

I don't consider the patch high risk. I think it is ready to pursue. I think
it's reasonable
to mark this as a newcomer issue. I would be willing to help work with anybody
who
has the time/motivation to push this forward.

Optimizer performance slowdown from 10.1 to 10.2

Key: DERBY-2130
URL: https://issues.apache.org/jira/browse/DERBY-2130
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4
Reporter: Bryan Pendleton
Labels: derby_triage10_5_2
Attachments: jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt,
plans.diff, repro.sql

Attached is 'repro.sql', an IJ script which demonstrates what I
believe to be a serious performance issue in the Optimizer.
I have run this script in a number of configurations:
- 10.1.2.1: the script runs successfully. The 'prepare' statement
takes about 90 seconds, on a fairly powerful Windows machine
- 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777
- 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement
often takes about 220 seconds, on the same Windows machine
Intermittently, on 10.2 and on the trunk, the prepare statement takes
15+ minutes. I cannot reliably reproduce this; I run the same script
several times in a row and I cannot predict whether it will take 220
seconds or whether it will take 15+ minutes.
I am quite motivated to work on this problem, as this is blocking me from
using Derby for a project that I'm quite keen on, but I need some
suggestions and ideas about how to attack it. From my perspective
there are 3 primary topics:
1) Why did optimizer performance for this query degrade so significantly
from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower,
for this particular query at least, in 10.2. Sometimes it is 10x slower.
2) What is the source of the non-determinism? Why does the optimizer
often take 4 minutes to optimize this query on the trunk, but sometimes
take 15+ minutes? I don't believe that I'm changing anything from
run to run.
3) Can we improve the optimizer performance even beyond what it was
for 10.1.2? I realize that this is an ugly query, but I was hoping to
see an optimization time of 5-10 seconds, not 90 seconds (and certainly
not 220 seconds).
I have attempted to start answering some of these questions, with
limited success. Here is some of what I think I've discovered so far:
- the optimizer changes in 10.2 seem to have given the optimizer many
more choices of possible query plans to consider. I think this means
that, if the optimizer does not time out, it will spend substantially
more time optimizing because there are more choices to evaluate. Does
this by itself mean that the optimizer will take 2.5 times longer in
10.2 than it did in 10.1?
- something about this query seems to make the costing mechanism go
haywire, and produce extreme costs. While stepping through the
optimization of this query in the debugger I have seen it compute
costs like 1e63 and 1e200. This might be very closely related to
DERBY-1905, although I don't think I'm doing any subqueries here.
But maybe I'm misunderstanding the term subquery in DERBY-1905.
At any rate, due to the enormous estimated costs, timeout does not
occur.
- the WHERE clause in this query is converted during compilation to
an equivalent IN clause, I believe, which then causes me to run into
a number of the problems described in DERBY-47 and DERBY-713.
Specifically, rather than constructing a plan which involves 4
index probes for the 4 WHERE clause values, the optimizer decides
that an index scan must be performed and that it will have to process
the entire index (because the query uses parameter markers, not
literal values). So perhaps solving DERBY-47 would help me
- the optimizer in fact comes up with a decent query plan quite quickly.
I have experimented with placing a hard limit into the optimizer
timeout code, so that I can force optimization to stop after an
arbitrary fixed period of time. Then I have been able to set that
value to as low as 1 second, and the optimizer has produced plans
that then execute in a few milliseconds. Of course, I have only tried
this with a trivial amount of data in my database, so it's possible
that the plan produced by the optimizer after just a second of
optimizing is in fact poor, and I'm just not noticing it because my
data sizes are so small.
At this point, what would be

[jira] [Commented] (DERBY-672) Re-enable user defined aggregates

2012-09-27 Thread Rick Hillegas (JIRA)

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

Rick Hillegas commented on DERBY-672:
-

Thanks for the quick review, Knut. Tests passed cleanly for me. Committed
derby-672-09-ab-udtAggregates.diff at subversion revision 1391034.

Re-enable user defined aggregates
-

[jira] [Closed] (DERBY-3720) Add documentation for the connection URL property encryptionKeyLength

2012-09-27 Thread Kim Haase (JIRA)


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

Kim Haase closed DERBY-3720.


Resolution: Duplicate

This issue was duplicated by DERBY-4229, which has now been resolved.

 Add documentation for the connection URL property encryptionKeyLength
 -

 Key: DERBY-3720
 URL: https://issues.apache.org/jira/browse/DERBY-3720
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.0.2.0, 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.2.1, 10.3.3.0, 10.4.1.3
Reporter: Dag H. Wanvik
Priority: Minor

 This property seems to be active, but is not documented. See also DERBY-3711.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (DERBY-1721) DOCS - Retitle topics with duplicate titles in Dev Guide re: Encryption

2012-09-27 Thread Kim Haase (JIRA)


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

Kim Haase reassigned DERBY-1721:


Assignee: Kim Haase

 DOCS - Retitle topics with duplicate titles in Dev Guide re: Encryption
 ---

 Key: DERBY-1721
 URL: https://issues.apache.org/jira/browse/DERBY-1721
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
Reporter: Laura Stewart
Assignee: Kim Haase
Priority: Minor

 In the Developers Guide. there are 2 sections that contain information about 
 encryption. 
 In some cases there are topics with different content but with the same 
 titles. 
 There should not be duplicate titles in the Derby documentation.
 There is this section: 
 JDBC applications and Derby basics --Derby embedded basics --Working with 
 the database connection URL attributes 
 that has these topic titles: 
 --Using the databaseName attribute 
 --Shutting down Derby or an individual database 
 --Creating and accessing a database 
 --Providing a user name and password 
 --Encrypting a database when you create it 
 --Booting an encrypted database 
 --Specifying attributes in a properties object 
 Then there is this section: 
 Derby and Security --Encrypting databases on disk --Working with encryption 
 that has these topic titles: 
 --Encrypting databases on creation 
 --Creating the boot password 
--Specifying an alternate encryption provider 
--Specifying an alternate encryption algorithm 
 --Booting an encrypted database 
 --Changing the boot password 
 Someone needs to look at the content of these files, rework the information 
 and necessary, create the related links, and then retitle the topics to avoid 
 duplicate titles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-1721) DOCS - Retitle topics with duplicate titles in Dev Guide re: Encryption

2012-09-27 Thread Kim Haase (JIRA)


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

Kim Haase commented on DERBY-1721:
--

The section Working with the database connection URL attributes should point 
to Encrypting databases on disk for information on database encryption, since 
the latter section is the one cited by the Reference Manual topics on 
encryption.

The information in Encrypting a database when you create it and Creating an 
encrypted database with an external key should be added to Encrypting 
databases on creation. (The term external key is not used in the Reference 
Manual. Is it meaningful?)

Any duplicate information in the first Booting an encrypted database should 
be added to the second one.

 DOCS - Retitle topics with duplicate titles in Dev Guide re: Encryption
 ---

 Key: DERBY-1721
 URL: https://issues.apache.org/jira/browse/DERBY-1721
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
Reporter: Laura Stewart
Assignee: Kim Haase
Priority: Minor

 In the Developers Guide. there are 2 sections that contain information about 
 encryption. 
 In some cases there are topics with different content but with the same 
 titles. 
 There should not be duplicate titles in the Derby documentation.
 There is this section: 
 JDBC applications and Derby basics --Derby embedded basics --Working with 
 the database connection URL attributes 
 that has these topic titles: 
 --Using the databaseName attribute 
 --Shutting down Derby or an individual database 
 --Creating and accessing a database 
 --Providing a user name and password 
 --Encrypting a database when you create it 
 --Booting an encrypted database 
 --Specifying attributes in a properties object 
 Then there is this section: 
 Derby and Security --Encrypting databases on disk --Working with encryption 
 that has these topic titles: 
 --Encrypting databases on creation 
 --Creating the boot password 
--Specifying an alternate encryption provider 
--Specifying an alternate encryption algorithm 
 --Booting an encrypted database 
 --Changing the boot password 
 Someone needs to look at the content of these files, rework the information 
 and necessary, create the related links, and then retitle the topics to avoid 
 duplicate titles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Regression Test Report - Daily 1390582 - Sun DBTG

2012-09-27 Thread Ole . Solberg

[Auto-generated mail]

*Daily* 1390582/2012-09-26 18:00:07 MEST

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.7*
 lin
01747917479 0   .% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 0   .% derbyall
022 0   .% compatibility
022 0   .% demoSuite
 sol
UNKNOWNUNKNOWNUNKNOWN UNKNOWN   .% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
1164163 0   .% derbyall
F:1,E:021 0   .% compatibility
022 0   .% demoSuite
 sol32
01747917479 0   .% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 0   .% derbyall
022 0   .% compatibility
022 0   .% demoSuite
 vista-64
01745117451 0   .% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 0   .% derbyall
   NA NA NANA   compatibility
022 0   .% demoSuite
  Details in  
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-1390582.html
 
  Attempted failure analysis in
  
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/1390582_bySig.html
 

*Jvm: 1.6*
 lin
01735917359 0   1718.84% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 038.00% derbyall
022 0   114.59% compatibility
022 0   .% demoSuite
 sles
01735917359 0   1084.97% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 035.48% derbyall
022 0   100.65% compatibility
022 0   .% demoSuite
 sol
01734717347 0   1220.12% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 029.50% derbyall
022 072.68% compatibility
022 0   .% demoSuite
 sol32
01734717347 089.26% suitesAll
01515 046.15% jdbcapiAutoLoad
01414 058.33% JDBCDriversAll
01515 053.84% JDBCDriversClient
01414 0 8.33% JDBCDriversEmbedded
0164164 0   1114.15% derbyall
022 0   15150.00% compatibility
022 0   750.00% demoSuite
 solN+1
01734717347 0   157.92% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 031.12% derbyall
022 064.55% compatibility
022 0   .% demoSuite
 sparc
01734717347 0   623.33% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 023.02% derbyall
022 075.12% compatibility
022 0   .% demoSuite
 vista
01732917329 0   206.36% suitesAll
01515 0   .% jdbcapiAutoLoad
01414 0   .% JDBCDriversAll
01515 0   .% JDBCDriversClient
01414 0   .% JDBCDriversEmbedded
0164164 044.31% derbyall
   NA NA NANA   compatibility
022 0   .% demoSuite
 vista-64
01732917329 0   301.89% suitesAll
01515 0   .% jdbcapiAutoLoad
01414

[jira] [Updated] (DERBY-5411) Client that does not have Security manager permission to connect gets ERROR 08006: Insufficient data while reading from the network Message should be clearer

2012-09-27 Thread Kathey Marsden (JIRA)


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

Kathey Marsden updated DERBY-5411:
--

Description: 
I was doing a little remote testing for the release candidate and noticed if a 
machine does not have permission to connect, then the client shows the 
following exception:
ij connect  'jdbc:derby://x.xx.xxx.xx:1527/wombat';
ERROR 08006: Insufficient data while reading from the network - expected a 
minimum of 6 bytes and received only 0 bytes.  The connection has been term
inated.
java.sql.SQLNonTransientConnectionException: Insufficient data while reading 
from the network - expected a minimum of 6 bytes and received only 0 byte
s.  The connection has been terminated.
at 
org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:322)
at java.sql.DriverManager.getConnection(DriverManager.java:297)
at org.apache.derby.impl.tools.ij.ij.dynamicConnection(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ConnectStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.ij.ijStatement(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
at org.apache.derby.impl.tools.ij.Main.main(Unknown Source)
at org.apache.derby.tools.ij.main(Unknown Source)
Caused by: org.apache.derby.client.am.DisconnectException: Insufficient data 
while reading from the network - expected a minimum of 6 bytes and receiv
ed only 0 bytes.  The connection has been terminated.
at org.apache.derby.client.net.Reply.fill(Unknown Source)
at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown 
Source)
at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown 
Source)
at 
org.apache.derby.client.net.NetConnectionReply.readExchangeServerAttributes(Unknown
 Source)
at 
org.apache.derby.client.net.NetConnection.readServerAttributesAndKeyExchange(Unknown
 Source)
at 
org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
 Source)
at 
org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.init(Unknown Source)
at org.apache.derby.client.net.NetConnection40.init(Unknown Source)
at 
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
 Source)
... 12 more

It would be good to have a clearer error message:

To Reproduce, use the script and policy file below changing the url for 
derby.codejars to the correct path for  your enviroment also in the policy file 
my.policy exchange x.x.x.x with the permitted host and y.y.y.y with the 
disallowed host.  Then try to connect from the disllowed host with connect  
'jdbc:derby://x.x.x.x:1527/wombat';

Script startServer.sh:
java  -Djava.security.manager 
-Dderby.codejars=file:c:/cygwin/home/kmarsden/projects/10.8.2testing/db-derby-10.8.2.1-lib/lib/
 -Djava.security.policy=my.policy org.apache.derby.drda.NetworkServerControl 
start -h 0.0.0.0

Policy File my.policy (change x.x.x.x and y.y.y.y) to the allowed and 
disallowed host respectively. )Since the y.y.y.y line is commented it is not 
really relevant except for testing that remote connections work properly)


grant codeBase ${derby.codejars}derby.jar
{
//
// These permissions are needed for everyday, embedded Derby usage.
//
  permission java.lang.RuntimePermission createClassLoader;
  permission java.util.PropertyPermission derby.*, read;
  permission java.util.PropertyPermission user.dir, read;
  permission java.util.PropertyPermission derby.storage.jvmInstanceId, 
  write; 
  permission java.io.FilePermission ${user.dir}${/}-, read;
  permission java.io.FilePermission ${derby.system.home},read;
  permission java.io.FilePermission ${derby.system.home}${/}-, 
read,write,delete;

//
// This permission lets a DBA reload the policy file while the server
// is still running. The policy file is reloaded by invoking the
// SYSCS_UTIL.SYSCS_RELOAD_SECURITY_POLICY() system procedure.
//
  permission java.security.SecurityPermission getPolicy;

//
// This permission lets you backup and restore databases
// to and from arbitrary locations in your file system.
//
// This permission also lets you import/export data to

65 matches

Mail list logo