I have tried to ping Scott privately on the email address linked to his
name: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. The mail was
undeliverable. At the risk of incurring my peers' censure, I will page
him in the subject line of an email message. I do think this is an
important enhancement
Hi Scott,
Please forgive me for putting you on the spot by paging you in the
subject line of this message. I have tried to privately ping your JIRA
email address ([EMAIL PROTECTED] mailto:[EMAIL PROTECTED]), but the
mail bounced back.
You graciously volunteered to work on DERBY-396. The
Hi Darcy,
Thanks for this update. I will unassign DERBY-396. I will happily to
mouse into DERBY-396 any information you think is worth forwarding.
Regards,
-Rick
Darcy Benoit wrote:
Rick,
Scott was one of my students, and he was working on DERBY-396. He
has since graduated and moved
Hi Andrew,
I heard a vague rumor that the 10.2 distributions would look different
than the 10.1 distributions available at
http://db.apache.org/derby/releases/release-10.1.2.1.cgi. Have you heard
this rumor and if so can you elaborate?
Thanks,
-Rick
Thanks, Andrew. What new items are we likely to see inside the
distributions?
Cheers,
-Rick
Andrew McIntyre wrote:
On 3/1/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Hi Andrew,
I heard a vague rumor that the 10.2 distributions would look different
than the 10.1 distributions available
Hi Kristian,
...
I just looked at the patch quickly, and it solves the problem in the
same way I was thinking about. I will try it out. Any specific reason
why the patch is not attached to DERBY-623 in Jira?
Two lazy reasons: 1) The JIRA itself doesn't have a test case. The
problem only
Hi Lance,
Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to contain
additional, trailing columns, above and beyond the columns required by
Someday, we may start converting legacy tests to an assertion-based
model. When we do that, I recommend starting with these tests which have
generated a spray of different canons for different platforms.
Regards,
-Rick
Knut Anders Hatlen (JIRA) wrote:
[
Hi Andrew,
Running -verbose, I see the following error. For the record, I'm running
on cygwin/xp with Ant 1.6.5. Thanks for your advice-Rick
dita.fo2pdf:
[fop] [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser
[fop] [INFO] Using org.apache.xerces.parsers.SAXParser as
getting Service Temporarily Unavailable errors when I try to open a
new JIRA. I think this bug masks quirks.
Regards,
-Rick
Andrew McIntyre wrote:
On 3/6/06, Rick Hillegas [EMAIL PROTECTED] wrote:
/snip
[fop] [INFO] [10]
[fop] [ERROR] Error while creating area : Error while
When I run a 10.2 server (built from the mainline) and try to connect to
a 10.1 database, I get the following error:
ERROR XJ040: Failed to start database 'testdb10.1', see the next
exception for details.
ERROR XCW00: Unsupported upgrade from '10.1' to '10.2 beta'.
Does this mean that soft
Can someone point me at a primer which describes how developers test
soft and hard upgrade? There is some customer-oriented discussion of
upgrade in the Developer's Guide and on the Wiki (at
http://wiki.apache.org/db-derby/UpgradingTen). But I can't find any
pointers on the testing web page
I would be surprised if the subject lines of these granular JIRAs made
their way into the Release Notes. We subdivide tasks into bite-sized
JIRAs to help developers and reviewers digest large features. I think
we'll just confuse our customers if we expose this detail of our
development
Hi Knut Anders,
Thanks for cleaning up this regression.
Cheers,
-Rick
Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1128?page=all ]
Knut Anders Hatlen closed DERBY-1128:
-
Resolution: Fixed
Committed revision
manager's job!
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I would be surprised if the subject lines of these granular JIRAs made
their way into the Release Notes. We subdivide tasks into bite-sized
JIRAs to help developers and reviewers digest large features. I think
we'll
I'm looking for an explanation of how Soft Upgrade is supposed to work,
from the customer's perspective and from the developer's perspective. I
suppose that this also entails an explanation of the inverse operation,
Soft Downgrade. I can't find this explanation.
My naive understanding of soft
Hi Øyvind,
Welcome back! Delighted to see you have not escaped our gravitational pull!
Personally, I don't have any strong feelings about this JIRA, but it is
grounded in the real customer experience of Dan Meany. For the record,
the relevant section of the SQL 2003 spec is Part 2, section
Hi David,
A couple responses follow. Cheers-Rick
David W. Van Couvering wrote:
Hi, Rick, this looks great, thanks for this work!
A couple of questions:
- Is there any reason these weren't written as JUnit tests? I suspect
the answer is (a) they were originally written before the JUnit
://issues.apache.org/jira/browse/DERBY-1133
Project: Derby
Type: Improvement
Components: Test
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Attachments: bug1133.diff, bug1133_rev2.diff
Right now the jdbc4 suite runs under the DerbyNetClient. However, under the
covers
Mike Matrigali wrote:
The way I look at it, derby has a very nice default. We call it soft
upgrade, but in my mind it really is no upgrade. We guarantee that
if you do nothing to your existing app, then you can run it and the
database against your current version of the derby software and all
have a process for guaranteeing that
future database changes end up in the right bucket?
Thanks,
-Rick
Daniel John Debrunner wrote:
Discussion moved to derby-dev
Rick Hillegas wrote:
Soft Upgrade is a feature which I think was introduced after I left
Cloudscape. Please bear with me as I
Hi David,
Yes, that is my understanding. I don't know any other way to address
defects discovered during the stabilization/trashathon period.
Regards,
-Rick
David W. Van Couvering wrote:
I was wondering if I could get some clarity here. Feature freeze is
soon approaching, but won't we be
Anurag has posted a patch for DERBY-1137, which refactors the embedded
DataSources to account for new methods introduced by JDBC4. Reviewers
are welcome to take a look at this code. Dan, your expertise in the
embedded client would be particularly useful here.
Thanks,
-Rick
Daniel John Debrunner wrote:
Deepa Remesh wrote:
On 3/22/06, Rick Hillegas [EMAIL PROTECTED] wrote:
It appears that changes to the database are partitioned into two
buckets: those accomplished by Hard Upgrade and those accomplished by
Soft Upgrade. Examples of Soft Upgrade changes
Hi Bryan,
Sorry to not get back to you sooner. I have been at an offsite all day
and am only now plowing through my email.
1) The Network server appears to be coming up with a security manager
and policy file
2) I did a diff between that policy file and what's in the codeline, and
they
Hi Bryan,
Glad to hear that this moved the problem forward. I will log a bug after
JIRA comes back up.
Regards,
-Rick
Bryan Pendleton wrote:
4) My classpath is wired together out of the classtree under
trunk/classes and the jar files in trunk/tools/java.
Thanks, Rick, that was exactly
Hi David,
I agree that this is a good goal. However, I wouldn't say that this is
the most important discrepancy distinguishing our clients. It seems to
me that client-convergence, including SQLState agreement, is a big
project, requiring a systematic plan. I say, keep closing the gap on an
Hi David,
There's clearly a compatibility issue here. Reasonable applications do
look at the SQLStates of caught exceptions. However, I think our
guidelines let us fix incorrect SQLStates--including making the Network
and Embedded clients agree. I would recommend listing SQLState changes
in
I think that this test is the gold-standard. It supplies a missing
sanity check which won't be available until we have a TCK for JDBC4.
Thanks for writing this test, Knut Anders.
Regards,
-Rick
Knut Anders Hatlen wrote:
Andreas Korneliussen [EMAIL PROTECTED] writes:
This is very
A while ago, I volunteered to manage a Derby release which will include
a new feature that is important to me: an implementation of JDBC4. Based
on the JDBC4 schedule then, I had hoped to post that release in June.
However, because the JDBC4 schedule moved back, I must post my release
later,
Hi David,
This is great. Thanks for pulling this together. I have one nit:
Currently, we say that the Release Notes document only changes to
Unstable interfaces. I think the Release Notes should document changes
to Stable and Standard interfaces (which ought to be rare), and the
Release
Note that our current nightly snapshots don't contain the jdbc40
classes. We could:
1) Change the nightly build to always generate the jdbc40 support or
2) Hand-generate a snapshot early in May
(1) seems more useful to me.
Regards,
-Rick
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
I need to push back the freeze date for the JDBC4 work. The following
issues have created more work than I originally estimated:
1) Upgrade issues raised by Kathey, tracked in DERBY-1107
2) Missing method signatures, tracked by DERBY-1146
3) The continued evolution of the JDBC4 spec itself
4)
expenses.
2) The value of getting early feedback.
3) The cost of premature feedback on half-baked code.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I need to push back the freeze date for the JDBC4 work. The following
issues have created more work than I originally
Hi David,
I think you may have already addressed the following issues in email,
but I don't see the results rolled onto the wiki page. Please pardon my
nitpicking. This kind of discussion turns me into a tiresome, pedantic
Mr. Hyde:
1) The cardinal rule. I recommend wordsmithing the
Thanks, David. I think this discussion is raising some interesting issues.
David W. Van Couvering wrote:
2) Bug fixing policy.
I think that the Exceptions section should say explicitly that It is
OK for minor releases to fix bugs in our implementation of the
standards, even if those
around here
without someone worrying whether than sneeze was compatible with your
last sneeze :)
David
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Thanks, David. I think this discussion is raising some interesting
issues.
David W. Van Couvering wrote:
2) Bug fixing policy.
I
Kathey Marsden wrote:
I still need to think a lot about the whole major version boundary
thing. It seems like we like solaris will be set at the same major
version for a very long time. As I stated before I think for some
things a time based approach seems most appropriate. You can expect
Hi Bryan,
Yes, please drop in your changes first. It turns out I'm going to have
to regenerate this patch because a boatload of canon changes went in
over the weekend. Are you planning to commit your changes today? It
would be great if I could merge and regenerate mid-afternoon San
Francisco
In previous lives, I've seen code-coverage metrics generated on, say, a
monthly basis and used as a release barrier. I do not think they are
appropriate as a barrier to checkin.
Regards,
-Rick
Kathey Marsden wrote:
David W. Van Couvering wrote:
Did I ask this before? Do we want to
Thanks, Kathey. This seems reasonable to me.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
So, I'm unclear: Are you still blocking metadata changes or are you
satisfied with the analysis done so far by Knut Anders and Dyre? Can
we proceed with metadata checkins provided
I have committed a patch to DERBY-955 which eliminates several
jdk1.6-specific canons. If you are working on a patch which touches
those files. you will want to merge with the mainline.
Regards,
-Rick
Hi Jean,
I share your general sense of disappointment with SQL but I don't think
that this community could do much better.
1) SQL is a language designed by a committee. That's why it's so
sprawling and inconsistent. I think that, very quickly, another
community-designed language would be
In my work on DERBY-930, I have written a test which needs to figure out
whether it is running against jar files or against the class path. This
requires granting the following permission on the classtree:
permission java.lang.RuntimePermission getProtectionDomain;
This, in turn, breaks an
Hi Dan,
I believe this has exposed a jdk bug. I think it's being worked on.
Thanks for raising the issue.
Regards,
-Rick
Daniel John Debrunner wrote:
Anurag Shekhar wrote:
Daniel John Debrunner wrote On 04/10/06 23:54,:
In the properties file for the TestQueryObject JDBC 4.0
Hi Andrew,
I thought that the mustang builds were generally available at
http://download.java.net/jdk6/binaries/. Does this download site not
work for you?
Regards,
-Rick
Andrew McIntyre wrote:
On 4/11/06, Myrna van Lunteren [EMAIL PROTECTED] wrote:
I think the build may be broken. My
This is good news. I think we're ready now to wire the jdbc40 suite into
derbyall (it should only run on jdk16).
BTW, my last derbyall on jdk14 reported that it ran 645 tests.
Regards,
-Rick
Andrew McIntyre wrote:
On 4/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
*Derby*
Thnanks, Andrew, I will try this with whatever JavaCC I can.
Cheers,
-Rick
Andrew McIntyre wrote:
On 4/12/06, Rick Hillegas (JIRA) derby-dev@db.apache.org wrote:
[
http://issues.apache.org/jira/browse/DERBY-1079?page=comments#action_12374225 ]
Rick Hillegas commented on DERBY-1079
be
built anyway.
Cheers,
-Rick
Andrew McIntyre wrote:
On 4/12/06, Rick Hillegas (JIRA) derby-dev@db.apache.org wrote:
[ http://issues.apache.org/jira/browse/DERBY-1079?page=all ]
Rick Hillegas reassigned DERBY-1079:
Assign To: Rick Hillegas
Andrew McIntyre wrote:
ships in the release.
For the engine docs, I'd suggest a similar setup. If you don't exclude
the jdbc40 classes, I'm pretty sure that javadoc will still find them
in the source and complain if it can't find the corresponding compiled
classfile.
Ah, I think you're
Thanks, Andrew. I was just setting up to run this test. I think your
proposal is a winner.
Regards,
-Rick
Andrew McIntyre wrote:
On 4/12/06, Andrew McIntyre [EMAIL PROTECTED] wrote:
As mentioned previously, why not go with 4.0? The RuntimeException
change only affects the mtGrammar
On my similalry configured machine, debyall takes about half a day to
run. This contrasts with its behavior last July, when it took maybe 3-4
hours. It's my impression that derbyall takes significantly longer to
run this week than it did last week. Here are my unscientific musings:
1) On my
Hi Army,
This is probably the issue I was referring to. If it's resolved, that's
great.
Thanks,
-Rick
Army wrote:
Rick Hillegas wrote:
2) I seem to recall that, earlier this year, optimizer modifications
bloated up the the per-query running time.
Ummm...I think I'm the only one who
Hi Jean,
I have lost the ability to add comments to JIRAs. I used to see a panel
on the left which listed a number of options, including Comment. Now
that panel is empty. I killed all my browsers and started a new one but
the problem persists.
Regards,
-Rick
Jean T. Anderson wrote:
Jean
Thanks Michelle and Jean, this fixed my problem.
Cheers,
-Rick
Michelle Caisse wrote:
Hi Rick,
You may have to log in again.
-- Michelle
Rick Hillegas wrote:
Hi Jean,
I have lost the ability to add comments to JIRAs. I used to see a
panel on the left which listed a number of options
I have checked in a change to the way that we generate javadoc: If
ant.properties points at a jdk16 installation, then we use the jdk16
javadoc tool and include JDBC4 support classes in derbydocs and in the
published api. If ant.properties does not point at a jdk16 installation,
then we use
I've been generating javadoc a lot this week and have been cleaning up
several empty @return tags. Typically these look like this:
@param foo blah blah blah
@param bar blah blah blah
@return
I would appreciate it if people would take a moment to remove these
vacuous @return tags before
Thanks, Andrew!
Andrew McIntyre wrote:
On 4/14/06, Rick Hillegas [EMAIL PROTECTED] wrote:
I have checked in a change to the way that we generate javadoc: If
ant.properties points at a jdk16 installation, then we use the jdk16
javadoc tool and include JDBC4 support classes in derbydocs
I'm seeing the following failure in a clean client torn off the
mainline. This is a diff in the DerbyNetClient run of the jdbc4 test
TestResultSetMethods. I'm running under mustang build 78.
MasterFileName = master/TestResultSetMethods.out
0 add
Unexpected exception caught SQL Exception:
When I bring up a 1.6 network server and issue this command outside the
test, I don't see the error.
Regards,
-Rick
Bryan Pendleton wrote:
Rick Hillegas (JIRA) wrote:
With this submission, we are down to the wisconsin noise plus some
diffs in sysinfo and sysinfo_withProperties.
Can you
)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.processCommands(Unknown
Source)
at
org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(Unknown
Source)
at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)
Bryan Pendleton wrote:
Rick Hillegas wrote:
Testing Sysinfo
Dang. I just synced with the mainline and now when I build under 1.4,
the build complains that it can't find javax.transaction.xa:
[javac]
C:\cygwin\home\rh161140\derby\mainline\trunk\java\engine\org\apache\derby\iapi\store\access\xa\XAResourceMan
ager.java:27: package
Oh bother. I have synced up to revision 395720. That fixes the build
problem, but now I'm getting UnsupportedClassVersionError again when I
run jdbcapi/metadata.java under DerbNetClient on jdk1.3.
-Rick
Andrew McIntyre wrote:
On 4/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Rick
in my tests was that for one of the data sources
the serialversion UID was not public, so I was getting failures. Now
I can't remember if I checked in that fix or not.
David
Rick Hillegas wrote:
I'm confused about the presence of serialVersionUIDs in the
DataSources exposed by our network client
I'm getting errors like the following when I build the user docs. Would
appreciate advice about how to fix this. Thanks-Rick
[echo]
*
[echo] * input =
getting an incompatible class error or whatever it's called. I was
doing everything perfectly, and it was still breaking. Once I set the
serialVersionUID to be public, peace reigned.
David
Rick Hillegas wrote:
Thanks, Lance. I agree. We seem to have a muddle if someone adds a
new non-transient
to the test
suite for any serializable objects
Rick Hillegas wrote:
Thanks, Lance. I agree. We seem to have a muddle if someone adds a
new non-transient field to one of these classes: either a) the
engineer changes the serialVersionUID, giving rise to the problem you
mention or b
for you?
-jean
Rick Hillegas wrote:
I'm getting errors like the following when I build the user docs. Would
appreciate advice about how to fix this. Thanks-Rick
[echo]
*
[echo] * input =
C:\cygwin\home\rh161140\derby\docs
My last checkin wired a new test (AutoloadTest) into the jdbc40 suite.
To run the jdbc40 suite cleanly against the Derby jar files, you now
need build 81 of jdk1.6.
Regards,
-Rick
Hi Andrew,
Yes, I'm still planning to manage a JDBC4-capable Derby release to go GA
soon after Mustang (jdk1.6) goes GA in September/October. Bryan and Knut
have expressed some concern that the Mustang schedule may slip. Although
I do not foresee a Mustang schedule slip, I acknowledge the
Does anyone have a theory about these failures? I have successfully run
some of the failed tests on linux and on xp/cygwin, using build 81 of
jdk1.6: derbynet/DerbyNetAutoStart, nist/schema1, and the encryptionAll
suite.
Regards,
-Rick
Hi, David.
Thanks to Anurag for wiring in the Ease-of-Development features, the
focus of this blog. Unfortunately, Brian tried to test our
driver-autoloading the day before this feature hit the mainline. I'm
afraid I don't understand Brian's problem with autogenerated keys.
Thanks for
Right now the javadoc generated for jdk1.6 is telling a shocking lie. I
can fix this but only by inducing javadoc to tell a different lie. I
would like advice on how to get javadoc to tell the truth, the whole
truth, and nothing but the truth. If that's not possible, I'd like to
know which lie
short of facts, but they were two ideas I thought
I'd put out there to see if they might help.
David
Rick Hillegas wrote:
Right now the javadoc generated for jdk1.6 is telling a shocking lie.
I can fix this but only by inducing javadoc to tell a different lie.
I would like advice on how to get
Hi Bryan,
When playing around with individual tests--enabling and disabling the
SecurityManager--I have noticed that our tests run considerably slower
when launched under the SecurityManager. I don't have any sense of how
much of the problem is just a tax we have to pay for security. Sounds
I believe that Knut Anders is working on a fix to this problem. In the
meantime, I have introduced another instance of this warning with svn
revision 398594. I think that May Day is a holiday in Norway, but Knut
Anders should be back tomorrow.
Regards,
-Rick
David W. Van Couvering wrote:
I
Hi Andrew,
Thanks to your excellent work on derby-1078, it appears that we use the
1.6 javac when compiling in a shell window whose JAVA_HOME points at a
1.6 installation. Thanks to your changes, the build targets tell the 1.6
compiler to regard pre-JDBC4 source as down-rev and to generate
+1 Yes, indeed.
Jean T. Anderson wrote:
This vote is for establishing Halley Pacheco de Oliveira as a
documentation committer for Derby.
Halley has translated the Derby Getting Started Guide and the Derby
Reference to Brazilian Portuguese (DERBY-780, DERBY-1138) and tells me
the Derby Server
Hi Lance,
Here's another gap between Derby's JDBC3 implementation and a reasonable
interpretation of the spec: Currently, Derby supports CallableStatement
methods of the form:
getXXX( int paramNumber) and
setXXX( int paramNumber, FOO paramValue )
but Derby does not implement the
driver?
David
Rick Hillegas (JIRA) wrote:
JDBC4 Compliance
Key: DERBY-1281
URL: http://issues.apache.org/jira/browse/DERBY-1281
Project: Derby
Type: Improvement
Components: JDBC Versions: 10.2.0.0Reporter: Rick
Hillegas
Fix
Thanks to everyone who responded to this thread. It doesn't seem that
anyone has a solution to this problem. Does anyone have a preference for
which lie we tell: (1b) or (2d)? Barring a preference here, the default
would be (1b), our current behavior.
Thanks,
-Rick
Rick Hillegas wrote
not obvious. :-)
Craig
Thanks to everyone who responded to this thread. It doesn't seem that
anyone has a solution to this problem. Does anyone have a preference
for which lie we tell: (1b) or (2d)? Barring a preference here, the
default would be (1b), our current behavior.
Thanks,
-Rick
Rick
Thanks to Andrew and David for carrying this useful discussion forward.
I have a couple comments::
1) Concerning the ant code below: I would feel better if we factored
this code up into the init target. Hopefully, all targets end up calling
init one way or another.
2) I applied the proposed
://issues.apache.org/jira/browse/DERBY-1079
Project: Derby
Type: Bug
Components: Build tools
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Fix For: 10.2.0.0
Attachments: bug1079_clientPublicAPI.diff, bug1079_deprecated.diff,
bug1079_embeddedPublicAPI.diff
Type: Improvement
Components: JDBC
Versions: 10.2.0.0
Reporter: Rick Hillegas
Assignee: Knut Anders Hatlen
Fix For: 10.2.0.0
The following statement raises an error in Derby:
statement.executeQuery( {call foo()} );
although this statement works
a more capable, top level index.html
and wrestle with the release machinery to get it into our release
distributions
Hope I'm not talking at cross-purposes still.
Thanks,
-Rick
Andrew McIntyre wrote:
On 5/9/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Hi Andrew,
I don't think I understand
Thanks, Andrew,
A couple more small points:
Andrew McIntyre wrote:
On 5/9/06, Rick Hillegas [EMAIL PROTECTED] wrote:
Is the following then a fair summary of your patch comment:
o I will remove my index.html from the patch
o At your leisure, you can create a more capable, top level
Hi Ramandeep,
This issue is covered by the umbrella DERBY-955 jira. The problem has
been analyzed this far: The tests run cleanly against the classtree but
fail because of permissions exceptions when run against jar files. We
suspect an asymmetry in the permissions granted to the classtree
SQLFeatureNotSupportedException. What are your thoughts?
Thanks,
-Rick
---BeginMessage---
[
http://issues.apache.org/jira/browse/DERBY-1316?page=comments#action_12379131 ]
Rick Hillegas commented on DERBY-1316:
--
I see that neither true nor false is completely satisfying
Dear Derby users,
Please read this message if you work on an application server or in an
application layer which cares about distributed transactions and/or
pooled connections.
Right now the inheritance graph for Derby's DataSources does not mirror
the corresponding graph of interfaces in
Thanks for forwarding this, Kathey.
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
Dear Derby users,
0Please read this message if you work on an application server or in
an application layer which cares about distributed transactions
and/or pooled connections.
Right now
):
java.security.AccessControlException'.
Oddly enough, the nist tests pass if run under 1.6 and standalone
against the jar files (that is, not under derbyall).
We're clearly not getting this error in the tinderbox tests run against
jars under 1.4.
Regards,
-Rick
Andrew McIntyre wrote:
On 5/10/06, Rick
Hi Andrew,
Could there be some extra magic which
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease should document?
When I follow the steps in (2), I get an error. Here are the steps:
587 ant clobber
588 ls
589 rm -rf jars
590 rm -rf javadoc
591 rm -rf snapshot
592 ls
593
396638 enabled driver autoloading (DERBY-930). It's the patch which
required us to migrate to Mustang build 81--that build fixes a bug which
short-circuited autoloading from jar files under a SecurityManager. With
DERBY-930 in place, the vm will execute its autoloading logic when
running
Hi Satheesh,
It looks to me like this is a new test introduced by revision 386710 to
close DERBY-1117. Testing getCause() appears to be central to what this
test wants to verify. Maybe we shouldn't run this test on 1.3.
Regards,
-Rick
Satheesh Bandaram wrote:
Looks like this test was
as it finds a driver which claims to
understand the connection url. It is puzzling that the problem only
occurs when the db2jcc jar appears on the CLASSPATH. The db2jcc driver
name isn't scribbled inside that jar file so the autoloader shouldn't
see it.
-Rick
Olav Sandstaa wrote:
Rick
Hi Olav,
Which driver (Network or Embedded) do you expect should be loaded? Also,
what is your classpath when the test fails?
Thanks,
-Rick
]Olav Sandstaa wrote:
I have not found the real cause for why the Nist tests fail but here is a
short re-cap of my current findings - in case anyone
I would like to generate a 10.2 snapshot very soon. To do this, I need
advice from Andrew and the rest of the community.
Hi Andrew,
I would like the snapshot to describe itself. Here's my understanding of
how this is done:
1) I should summarize what we hope the community will test. This
Right now the mainline is marked as alpha quality. This will be true of
the upcoming snapshot we propose to cut off the mainline. Given the
alpha marker, databases created by the snapshot won't be upgradable.
What happens when we branch the mainline for the 10.2 release? At what
point do we
+1
David Van Couvering wrote:
This vote is for adding Suresh Thalamati as a committer to Derby.
Suresh has been contributing since the beginning of Derby. His
contributions to the storage layers of Derby have been quite valuable,
including his very valuable contribution of online backup, a
401 - 500 of 11787 matches
Mail list logo
