[jira] [Commented] (DERBY-6958) Clean up the Derby website

[Dimuthu Wickramanayake (JIRA)]

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

Dimuthu Wickramanayake commented on DERBY-6958:
---

I guess the file you need to edit at first is what i did upload above. Can you 
tell me where i can find those files in the source code i got it using curl.

> Clean up the Derby website
> --
>
> Key: DERBY-6958
> URL: https://issues.apache.org/jira/browse/DERBY-6958
> Project: Derby
>  Issue Type: Improvement
>  Components: Web Site
>Affects Versions: 10.13.1.1
>Reporter: Rick Hillegas
>Assignee: Dimuthu Wickramanayake
> Attachments: index.html
>
>
> The Derby website is stale and needs to be cleaned up. Here is an initial 
> list of things I want to clean up:
> 1) The copyright year in the page footer is 2015. That should be 2017. Extra 
> credit if we can parameterize the footer so that the copyright year is 
> automatically updated whenever we refresh the website with a new release.
> 2) The document references in the FAQ (http://db.apache.org/derby/faq.html) 
> are hard-coded. I just updated them from 10.7 doc references to be 10.13 
> references. But we should parameterize doc references across the Derby 
> website so that, again, they are updated whenever we refresh the website with 
> a new release.
> 3) I removed dead links in some of the top-level pages along with stale 
> information. We need to make a systematic pass through the whole website. 
> Extra credit if we can automate the location of dead links so that we can 
> clean up the website when we publish releases.
> 4) We need to remove material which addresses old issues which no-one cares 
> about any more.
> 5) Extra credit if we can cleanup the wiki similarly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (DERBY-6958) Clean up the Derby website

[Dimuthu Wickramanayake (JIRA)]

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

Dimuthu Wickramanayake updated DERBY-6958:
--
Attachment: index.html

> Clean up the Derby website
> --
>
> Key: DERBY-6958
> URL: https://issues.apache.org/jira/browse/DERBY-6958
> Project: Derby
>  Issue Type: Improvement
>  Components: Web Site
>Affects Versions: 10.13.1.1
>Reporter: Rick Hillegas
>Assignee: Dimuthu Wickramanayake
> Attachments: index.html
>
>
> The Derby website is stale and needs to be cleaned up. Here is an initial 
> list of things I want to clean up:
> 1) The copyright year in the page footer is 2015. That should be 2017. Extra 
> credit if we can parameterize the footer so that the copyright year is 
> automatically updated whenever we refresh the website with a new release.
> 2) The document references in the FAQ (http://db.apache.org/derby/faq.html) 
> are hard-coded. I just updated them from 10.7 doc references to be 10.13 
> references. But we should parameterize doc references across the Derby 
> website so that, again, they are updated whenever we refresh the website with 
> a new release.
> 3) I removed dead links in some of the top-level pages along with stale 
> information. We need to make a systematic pass through the whole website. 
> Extra credit if we can automate the location of dead links so that we can 
> clean up the website when we publish releases.
> 4) We need to remove material which addresses old issues which no-one cares 
> about any more.
> 5) Extra credit if we can cleanup the wiki similarly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [Derby issue #6909]

[Indumini Ayomi]

I reproduced the problem on my computer. I'm asking how best to go fixing
the problem.

Thank You.

On Tue, Sep 26, 2017 at 7:20 AM, Bryan Pendleton  wrote:

> Are you asking how to reproduce the problem on your computer?
>
> Or are you asking how best to go about fixing the problem?
>
> thanks,
>
> bryan
>
> On Mon, Sep 25, 2017 at 10:43 AM, Indumini Ayomi 
> wrote:
>
>> Hello,
>>
>> I am studying about issue #6909. But I don't have exact idea where the
>> place that issue happened. Could someone please guide me to do it ?
>>
>> Thank You.
>>
>
>

Re: [Derby issue #6909]

[Bryan Pendleton]

Are you asking how to reproduce the problem on your computer?

Or are you asking how best to go about fixing the problem?

thanks,

bryan

On Mon, Sep 25, 2017 at 10:43 AM, Indumini Ayomi 
wrote:

> Hello,
>
> I am studying about issue #6909. But I don't have exact idea where the
> place that issue happened. Could someone please guide me to do it ?
>
> Thank You.
>

Re: Regarding DERBY-5538

[Bryan Pendleton]

The crucial difference between using String, and using char[], is that the
String cannot be changed after we are done using it, while the char[] array
can be changed once we are done using it.

So it's not *just* changing from String to char[], it's *also* clearing the
character array after we are done using it, so it doesn't stick around in
memory unnecessarily.

Here's a more detailed explanation:
http://securesoftware.blogspot.com/2009/01/java-security-why-not-to-use-string.html

thanks,

bryan

[jira] [Commented] (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

[Kavin Ranawella (JIRA)]

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

Kavin Ranawella commented on DERBY-5411:


Can you please explain the steps that were followed to get the resulting 
errors? And the running of the .sh is not clear.

> Client that does not have Security manager permission to connect gets "ERROR 
> 08006: Insufficient data while reading from the network" Message should be 
> clearer
> ---
>
> Key: DERBY-5411
> URL: https://issues.apache.org/jira/browse/DERBY-5411
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.8.2.2
>Reporter: Kathey Marsden
>Assignee: Kavin Ranawella
>Priority: Minor
>  Labels: derby_triage10_9
>
> 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.(Unknown Source)
> at org.apache.derby.client.net.NetConnection40.(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 issue #6909]

[Indumini Ayomi]

Hello,

I am studying about issue #6909. But I don't have exact idea where the
place that issue happened. Could someone please guide me to do it ?

Thank You.

[jira] [Comment Edited] (DERBY-6931) ClientPreparedStatement doesn't support executeLargeBatch

[Mark Swatosh (JIRA)]

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

Mark Swatosh edited comment on DERBY-6931 at 9/25/17 3:34 PM:
--

[~himashasds] Sorry to step on your toes here a bit, but I actually ended up 
looking into this a little more this morning and now I've got a working fix in 
my environment. Would you mind letting me have this defect?


was (Author: mswatosh):
Sorry to step on your toes here a bit, but I actually ended up looking into 
this a little more this morning and now I've got a working fix in my 
environment. Would you mind letting me have this defect?

> ClientPreparedStatement doesn't support executeLargeBatch
> -
>
> Key: DERBY-6931
> URL: https://issues.apache.org/jira/browse/DERBY-6931
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.11.1.1, 10.12.1.1, 10.13.1.1
>Reporter: Mark Swatosh
>Assignee: Himasha De Silva
> Attachments: Main.java
>
>
> When trying to run executeLargeBatch on a PreparedStatement, the following 
> error is seen:
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to java.lang.String
>   at 
> org.apache.derby.client.am.ClientStatement.flowExecuteBatch(ClientStatement.java:2460)
>   at 
> org.apache.derby.client.am.ClientStatement.executeBatchX(ClientStatement.java:1292)
>   at 
> org.apache.derby.client.am.ClientStatement.executeLargeBatch(ClientStatement.java:1269)
>   at com.test.Main.main(Main.java:22)
> Upon further inspection, I found executeLargeBatch isn't implemented in 
> ClientPreparedStatement and it is using ClientStatement instead. It pulls in 
> the parameter for the PreparedStatement as a Statement, which is where the 
> ClassCastException occurs. I will attach a simple reproduction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6931) ClientPreparedStatement doesn't support executeLargeBatch

[Mark Swatosh (JIRA)]

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

Mark Swatosh commented on DERBY-6931:
-

Sorry to step on your toes here a bit, but I actually ended up looking into 
this a little more this morning and now I've got a working fix in my 
environment. Would you mind letting me have this defect?

> ClientPreparedStatement doesn't support executeLargeBatch
> -
>
> Key: DERBY-6931
> URL: https://issues.apache.org/jira/browse/DERBY-6931
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.11.1.1, 10.12.1.1, 10.13.1.1
>Reporter: Mark Swatosh
>Assignee: Himasha De Silva
> Attachments: Main.java
>
>
> When trying to run executeLargeBatch on a PreparedStatement, the following 
> error is seen:
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to java.lang.String
>   at 
> org.apache.derby.client.am.ClientStatement.flowExecuteBatch(ClientStatement.java:2460)
>   at 
> org.apache.derby.client.am.ClientStatement.executeBatchX(ClientStatement.java:1292)
>   at 
> org.apache.derby.client.am.ClientStatement.executeLargeBatch(ClientStatement.java:1269)
>   at com.test.Main.main(Main.java:22)
> Upon further inspection, I found executeLargeBatch isn't implemented in 
> ClientPreparedStatement and it is using ClientStatement instead. It pulls in 
> the parameter for the PreparedStatement as a Statement, which is where the 
> ClassCastException occurs. I will attach a simple reproduction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DERBY-6957) ERROR 40XL1: A lock could not be obtained within the time requested for alter or truncate table

[Lashan Faliq (JIRA)]

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

Lashan Faliq reassigned DERBY-6957:
---

Assignee: (was: Lashan Faliq)

> ERROR 40XL1: A lock could not be obtained within the time requested for alter 
> or truncate table
> ---
>
> Key: DERBY-6957
> URL: https://issues.apache.org/jira/browse/DERBY-6957
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.13.1.1
> Environment: production
>Reporter: SUNEEL KUMAR OLETI
>
> hi,
> for all my Drop table, alter table, truncate table i am getting below error.
> ERROR 40XL1: A lock could not be obtained within the time requested
>   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
>   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown 
> Source)
>   at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source)
>   at 
> org.apache.derby.impl.store.raw.xact.ContainerLocking3.lockContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
>  Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
>  Source)
>   at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown 
> Source)
>   at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source)
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.sql.execute.DDLConstantAction.lockTableForDDL(Unknown 
> Source)
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(Unknown
>  Source)
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(Unknown
>  Source)
>   at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown 
> Source)
>   at com.db.UpdateTables.alterDataTable(UpdateTables.java:1833)
>   at 
> com.he.webApiLayer.ResponseBuilder.insertDataInDB(ResponseBuilder.java:2910)
>   at com.he.webApiLayer.InputAPI.lambda$1(InputAPI.java:127)
>   at spark.RouteImpl$1.handle(RouteImpl.java:61)
>   at spark.http.matching.Routes.execute(Routes.java:61)
>   at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:128)
>   at 
> spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
>   at org.eclipse.jetty.server.Server.handle(Server.java:517)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> 

[jira] [Assigned] (DERBY-6957) ERROR 40XL1: A lock could not be obtained within the time requested for alter or truncate table

[Lashan Faliq (JIRA)]

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

Lashan Faliq reassigned DERBY-6957:
---

Assignee: Lashan Faliq

> ERROR 40XL1: A lock could not be obtained within the time requested for alter 
> or truncate table
> ---
>
> Key: DERBY-6957
> URL: https://issues.apache.org/jira/browse/DERBY-6957
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.13.1.1
> Environment: production
>Reporter: SUNEEL KUMAR OLETI
>Assignee: Lashan Faliq
>
> hi,
> for all my Drop table, alter table, truncate table i am getting below error.
> ERROR 40XL1: A lock could not be obtained within the time requested
>   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
>   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown 
> Source)
>   at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source)
>   at 
> org.apache.derby.impl.store.raw.xact.ContainerLocking3.lockContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
>  Source)
>   at 
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
>  Source)
>   at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown 
> Source)
>   at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source)
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.sql.execute.DDLConstantAction.lockTableForDDL(Unknown 
> Source)
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(Unknown
>  Source)
>   at 
> org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(Unknown
>  Source)
>   at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
>   at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown 
> Source)
>   at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown 
> Source)
>   at com.db.UpdateTables.alterDataTable(UpdateTables.java:1833)
>   at 
> com.he.webApiLayer.ResponseBuilder.insertDataInDB(ResponseBuilder.java:2910)
>   at com.he.webApiLayer.InputAPI.lambda$1(InputAPI.java:127)
>   at spark.RouteImpl$1.handle(RouteImpl.java:61)
>   at spark.http.matching.Routes.execute(Routes.java:61)
>   at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:128)
>   at 
> spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
>   at org.eclipse.jetty.server.Server.handle(Server.java:517)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> 

[jira] [Comment Edited] (DERBY-6924) Documentation improvement

[Kim Haase (JIRA)]

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

Kim Haase edited comment on DERBY-6924 at 9/25/17 2:24 PM:
---

I believe the person who filed the bug must be referring to the section "JDBC 
Connection Basics." The term "URL" is italicized the first time it is used, but 
not after that, unless it is used as an argument in a syntax statement.

The Derby documentation conventions can be found in the "Typographical 
conventions" section of the Getting Started Guide: 
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/getstart/getstartderby.pdf.
 

You can close this bug report as "Not a problem." Thanks!


was (Author: chaase3):
I believe you must be referring to the section "JDBC Connection Basics." The 
term "URL" is italicized the first time it is used, but not after that, unless 
it is used as an argument in a syntax statement.

You can find the Derby documentation conventions in the "Typographical 
conventions" section of the Getting Started Guide: 
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/getstart/getstartderby.pdf.
 

You can close this bug report as "Not a problem." 

> Documentation improvement
> -
>
> Key: DERBY-6924
> URL: https://issues.apache.org/jira/browse/DERBY-6924
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.12.1.1
>Reporter: Aaron Seavers
>Assignee: Dimuthu Wickramanayake
>Priority: Trivial
>  Labels: documentation
>
> I noticed in the documentation on 
> https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/tools/index.html
>  that database URL is italicized only once on the page. "Establishing a 
> connection to a specific database is done by specifying a appropriate 
> database URL". I dont know if this is intended or if the URL should be 
> regular type



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6924) Documentation improvement

[Kim Haase (JIRA)]

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

Kim Haase commented on DERBY-6924:
--

I believe you must be referring to the section "JDBC Connection Basics." The 
term "URL" is italicized the first time it is used, but not after that, unless 
it is used as an argument in a syntax statement.

You can find the Derby documentation conventions in the "Typographical 
conventions" section of the Getting Started Guide: 
https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/getstart/getstartderby.pdf.
 

You can close this bug report as "Not a problem." 

> Documentation improvement
> -
>
> Key: DERBY-6924
> URL: https://issues.apache.org/jira/browse/DERBY-6924
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.12.1.1
>Reporter: Aaron Seavers
>Assignee: Dimuthu Wickramanayake
>Priority: Trivial
>  Labels: documentation
>
> I noticed in the documentation on 
> https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/tools/index.html
>  that database URL is italicized only once on the page. "Establishing a 
> connection to a specific database is done by specifying a appropriate 
> database URL". I dont know if this is intended or if the URL should be 
> regular type



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6931) ClientPreparedStatement doesn't support executeLargeBatch

[Mark Swatosh (JIRA)]

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

Mark Swatosh commented on DERBY-6931:
-

You're probably getting an SqlException (I'm assuming?) because "" won't 
parse as a valid SQL Statement. You'll need something like "SELECT 
CustomerName, City FROM Customers;" to execute that code path.

> ClientPreparedStatement doesn't support executeLargeBatch
> -
>
> Key: DERBY-6931
> URL: https://issues.apache.org/jira/browse/DERBY-6931
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.11.1.1, 10.12.1.1, 10.13.1.1
>Reporter: Mark Swatosh
>Assignee: Himasha De Silva
> Attachments: Main.java
>
>
> When trying to run executeLargeBatch on a PreparedStatement, the following 
> error is seen:
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to java.lang.String
>   at 
> org.apache.derby.client.am.ClientStatement.flowExecuteBatch(ClientStatement.java:2460)
>   at 
> org.apache.derby.client.am.ClientStatement.executeBatchX(ClientStatement.java:1292)
>   at 
> org.apache.derby.client.am.ClientStatement.executeLargeBatch(ClientStatement.java:1269)
>   at com.test.Main.main(Main.java:22)
> Upon further inspection, I found executeLargeBatch isn't implemented in 
> ClientPreparedStatement and it is using ClientStatement instead. It pulls in 
> the parameter for the PreparedStatement as a Statement, which is where the 
> ClassCastException occurs. I will attach a simple reproduction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DERBY-6928) The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string values

[Indumini Ayomi (JIRA)]

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

Indumini Ayomi reassigned DERBY-6928:
-

Assignee: (was: Indumini Ayomi)

> The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string 
> values
> ---
>
> Key: DERBY-6928
> URL: https://issues.apache.org/jira/browse/DERBY-6928
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Reporter: Hao Zhong
>Priority: Minor
>
> As some values are defined in org.apache.derby.iapi.types.TypeId, it is 
> easier to maintain the code, if we replace them accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DERBY-6928) The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string values

[Indumini Ayomi (JIRA)]

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

Indumini Ayomi reassigned DERBY-6928:
-

Assignee: Indumini Ayomi

> The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string 
> values
> ---
>
> Key: DERBY-6928
> URL: https://issues.apache.org/jira/browse/DERBY-6928
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Reporter: Hao Zhong
>Assignee: Indumini Ayomi
>Priority: Minor
>
> As some values are defined in org.apache.derby.iapi.types.TypeId, it is 
> easier to maintain the code, if we replace them accordingly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DERBY-6958) Clean up the Derby website

[Dimuthu Wickramanayake (JIRA)]

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

Dimuthu Wickramanayake reassigned DERBY-6958:
-

Assignee: Dimuthu Wickramanayake

> Clean up the Derby website
> --
>
> Key: DERBY-6958
> URL: https://issues.apache.org/jira/browse/DERBY-6958
> Project: Derby
>  Issue Type: Improvement
>  Components: Web Site
>Affects Versions: 10.13.1.1
>Reporter: Rick Hillegas
>Assignee: Dimuthu Wickramanayake
>
> The Derby website is stale and needs to be cleaned up. Here is an initial 
> list of things I want to clean up:
> 1) The copyright year in the page footer is 2015. That should be 2017. Extra 
> credit if we can parameterize the footer so that the copyright year is 
> automatically updated whenever we refresh the website with a new release.
> 2) The document references in the FAQ (http://db.apache.org/derby/faq.html) 
> are hard-coded. I just updated them from 10.7 doc references to be 10.13 
> references. But we should parameterize doc references across the Derby 
> website so that, again, they are updated whenever we refresh the website with 
> a new release.
> 3) I removed dead links in some of the top-level pages along with stale 
> information. We need to make a systematic pass through the whole website. 
> Extra credit if we can automate the location of dead links so that we can 
> clean up the website when we publish releases.
> 4) We need to remove material which addresses old issues which no-one cares 
> about any more.
> 5) Extra credit if we can cleanup the wiki similarly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (DERBY-6960) Cleanup LOOKAHEADS in parser production for ALTER TABLE ALTER COLUMN

[Dimuthu Wickramanayake (JIRA)]

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

Dimuthu Wickramanayake reassigned DERBY-6960:
-

Assignee: Dimuthu Wickramanayake

> Cleanup LOOKAHEADS in parser production for ALTER TABLE ALTER COLUMN
> 
>
> Key: DERBY-6960
> URL: https://issues.apache.org/jira/browse/DERBY-6960
> Project: Derby
>  Issue Type: Task
>  Components: SQL
>Affects Versions: 10.14.1.0
>Reporter: Rick Hillegas
>Assignee: Dimuthu Wickramanayake
>
> The columnAlterClause() production has a lot of LOOKAHEADs. It is probably 
> possible to simplify this production and make it more readable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DERBY-6931) ClientPreparedStatement doesn't support executeLargeBatch

[Himasha De Silva (JIRA)]

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

Himasha De Silva commented on DERBY-6931:
-

The flowExecuteBatch() method in ClientStatement calls the 
parseSqlAndSetSqlModes(sql) method. For the sql parameter i passed a string 
""  then i get an exception. Can i know what type of String is expected for 
the sql parameter? Does it have a specific format?




> ClientPreparedStatement doesn't support executeLargeBatch
> -
>
> Key: DERBY-6931
> URL: https://issues.apache.org/jira/browse/DERBY-6931
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.11.1.1, 10.12.1.1, 10.13.1.1
>Reporter: Mark Swatosh
>Assignee: Himasha De Silva
> Attachments: Main.java
>
>
> When trying to run executeLargeBatch on a PreparedStatement, the following 
> error is seen:
> Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; 
> cannot be cast to java.lang.String
>   at 
> org.apache.derby.client.am.ClientStatement.flowExecuteBatch(ClientStatement.java:2460)
>   at 
> org.apache.derby.client.am.ClientStatement.executeBatchX(ClientStatement.java:1292)
>   at 
> org.apache.derby.client.am.ClientStatement.executeLargeBatch(ClientStatement.java:1269)
>   at com.test.Main.main(Main.java:22)
> Upon further inspection, I found executeLargeBatch isn't implemented in 
> ClientPreparedStatement and it is using ClientStatement instead. It pulls in 
> the parameter for the PreparedStatement as a Statement, which is where the 
> ClassCastException occurs. I will attach a simple reproduction.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Making patch

[Kristian Waagan]

Hello Dinuka,

Thanks for preparing a patch for Derby :)

Does the information here suffice to get you started?
https://db.apache.org/derby/derby_comm.html#Contribute+Code+or+Documentation


Regards,
-- 
Kristian


On man. 25. sep. 2017, 07:50 Dinuka Nadeeshan <
dinuka.nadeeshan1...@gmail.com> wrote:

> hi,
>
> Can someone please help me with how to make the patch using svn.
>
> thank you
>
>
> --
> *K. A. Dinuka Nadeeshan*
> Undergraduate of Dept. of Computer Engineering, Faculty of Engineering,
> University of Peradeniya, Sri-Lanka
> LinkedIn:* https://www.linkedin.com/in/dinuka-nadeeshan/
> *
> GitHub: *https://github.com/dinukanadeeshan
> *
>
>