Andrew McIntyre wrote:
On 1/25/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
That should be well defined by the JVM specification and updates from
Sun. Though I've never seen any definition of what the class major and
minor version imply, makes it hard to generate byte code. :-(
The
David W. Van Couvering wrote:
This vote is for establishing Rick Hillegas as a committer for Derby.
Please vote +1 if you approve of Rick as a committer.
+1
--
Jeremy
Bernt M. Johnsen wrote:
David W. Van Couvering wrote (2005-12-06 11:11:12):
Hi, all. Many of us will be at ApacheCon in San Diego next week. There
is a Derby BoF from 9:30 - 10:30 on Tuesday night. I was thinking that
perhaps those of us who are there could meet for an informal, Dutch
Treat
David W. Van Couvering wrote:
10. [X] (these all belong together...)
http://issues.apache.org/jira/secure/attachment/12321022/derby_logo_only.jpg
http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpg
, 2005, at 4:49 PM, [EMAIL PROTECTED] wrote:
The Geronimo project would like to upgrade to Derby 10.1.2.1 but we
need the Derby JARs placed in the Maven repository.
From memory Jeremy Boynes checked in some Maven files into the maven
directory that allow you to do this. Note
This seems similar (at least in my head) to DataSourceFactory here:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/browser
As Dan said, I think we need to be careful not to confuse the two
mechanisms for setting properties. However, I think there is a clear
separation between
[ http://issues.apache.org/jira/browse/DERBY-556?page=all ]
Jeremy Boynes closed DERBY-556:
---
Resolution: Cannot Reproduce
After Rick's changes (doh!) it works for me as well which means that I can't
remember what was broken with the original issue
[ http://issues.apache.org/jira/browse/DERBY-556?page=all ]
Jeremy Boynes updated DERBY-556:
Attachment: Derby556.java
Java program to illustrate the problem.
NetworkServer does not set thread context classloader
[
http://issues.apache.org/jira/browse/DERBY-556?page=comments#action_12357763 ]
Jeremy Boynes commented on DERBY-556:
-
This problem will not manifest if the procedure classes are on the system
classpath (${CLASSPATH}) - you need to be playing tricks
Rick Hillegas wrote:
I would like to propose that we include JUnit as part of the required
toolkit for Derby developers. Going forward, this will allow developers
to write assertion-based tests. For the moment, this will not change the
existing test harness.
+1 with the caveat that it
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Think of the carnage if it was java_14208_b13.sql_300.Connection
It's actually instructive to look how Java solves this:
- The interface is kept upwards compatible, by following rules such as
only new methods/fields etc.
Then to look
Evolution would start with a small change that was then built on and
expanded. From that perspective, starting with a small change like the
localization would be the beginning of an evolutionary change. Doing it
now, near the start of a feature release, and providing plenty of time
for
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
David W. Van Couvering wrote:
Can't you have the situation where common 10.2 and common 10.3 are
both included in the classpath (by accident, as Dan brings up)?
Wouldn't you end up with order dependencies then?
I feel my scenario keeps
Daniel John Debrunner wrote:
But as an aside, I once downloaded an open source project, which then
instructed me to fetch a further five or six common Apache libraries,
either at a specific version numbers or higher than a given version. I
followed all this correctly, set up the classpath and
David W. Van Couvering wrote:
Jeremy Boynes wrote:
[snip]
Daniel John Debrunner wrote:
The issue is that today this is fully supported because the client and
engine do not share code.
Some of the code sharing approaches regress Derby in this area by not
supporting this, or require class
Kathey Marsden wrote:
Jeremy Boynes wrote:
I think we get the equivalent behaviour by having the Monitor load the
NetworkServerControlImpl directly; alternatively we could have
JDBCBoot start it up explicitly.
I might be misunderstanding what you are proposing, but wouldn't this
cause
Daniel John Debrunner wrote:
Andrew McIntyre wrote:
I would be very tempted to veto any approach that had the jars
containing different code to that built in the classes directory and
usually(?) used for testing by developers. I believe it increases the
chance for problems being introduced in
David W. Van Couvering wrote:
I thought Kathey/Dan's idea of generating copies of the common code
into two separate directories was interesting and solved a lot of problems,
and I thought it would be worthwhile to walk through this in a bit more
detail.
This seems like a lot of build time
Kathey Marsden wrote:
Jeremy Boynes wrote:
In that context, components that come to mind are engine, client, net,
tools and common and external dependencies for consideration include
logging, configuration and thread management.
What type of version interoperability do you propose
The NetworkServerControlImpl starts its server using a DRDAServerStarter
which constructs a NetworkServerControlImpl via reflection. The
DRDAServerStarter is in the engine tree, the NetworkServerControlImpl is
in the drda tree.
Can someone please give a little historical background here.
Kathey Marsden wrote:
DRDAServerStarter is there in support of the
derby.drda.startNetworkServer property, an easy way to embed network
server in your application when you start Derby.
Given the drda code needs to be there for this to work, can we just move
this functionality into the
Daniel John Debrunner wrote:
Given the drda code needs to be there for this to work, can we just move
this functionality into the drda module (and hence derbynet)?
Some code is needed in the engine to look at the property and decide if
to boot the network server. I thought DRDAServerStarter
David W. Van Couvering wrote:
Well, this is an interesting wrench you have thrown in here, Jeremy.
Wrenches are a specialty of the house :-)
snip/
The question is, what are the benefits of the approach, and do they
merit the rigor that we would have to follow to make sure things don't
Jean T. Anderson wrote:
OK, Derby committers, you all have karma to the db site module.
Oyvind and Jeremy, please try your commit again and let me know.
Thanks, that worked. I'll leave the update to you as I think quite a few
people may do this close together.
--
Jeremy
Daniel John Debrunner wrote:
Jeremy, I'm having trouble understanding this.
The embedded engine requires classes for Java procedures to either be
available through the thread context classloader, the class loader for
Derby code, or through the database classpath using jars stored in the
Daniel John Debrunner wrote:
You or I might not, but I'm assuming the worst case where the end-user
has no idea about classpath, or maybe even Java. They have just
installed two applications, one which uses Derby client at version X and
one which uses Derby embedded at version Y.
I would
Francois Orsini wrote:
What's the current policy in respect with coding standards in Derby?
I would like to suggest that there is an extra efforts in commenting source
code and in particular class headers which are not there in lots of classes.
Due to the nature of Open Source, it is not
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
David W. Van Couvering wrote:
The common classes will be placed into both derby.jar and
derbyclient.jar. When you have a classpath with a network client at
one revision and the embedded driver at another revision, the jar with
the highest
Reporter: Jeremy Boynes
The NetworkServer does not set the thread context classloader which is used to
load the implementations of stored procedures. As a result, procedure
implementations must be present in the classpath of the engine itself; this
differs from embedded mode where classes may
David W. Van Couvering wrote:
The common classes will be placed into both derby.jar and
derbyclient.jar. When you have a classpath with a network client at one
revision and the embedded driver at another revision, the jar with the
highest revision should always go first, e.g
[EMAIL PROTECTED] wrote:
Jeremy,
Is there a reason why we didn't follow the groupId conventions that I
discussed in the email thread Placing 10.1.1.0 in Maven repository with
groupId that follows new policy ?
I used the name of the main source package as the groupId as I believed
that
Don't think this really needs a vote - submit a patch that adds this
functionality and it will be accepted, revised or rejected.
Anyway, from my perspective, +1 assuming all the appropriate changes are
made to code, tests and documentation.
--
Jeremy
Rick Hillegas wrote:
I propose to close
I have uploaded the 10.1.1.0 release jars (from the lib distro) to the
offical Apache Maven repository at
http://www.apache.org/dist/java-repository under the groupId
org.apache.derby
It will take a couple of hours for the repo to rsync to the live site
and soon after that they should also
How about adding a JAR into java/jars with just the necessary interfaces
in it? This is common at Apache for API classes that projects need to
compile against (like the geronimo-spec-jta jar we have).
--
Jeremy
Andrew McIntyre wrote:
On 8/8/05, Rick Hillegas [EMAIL PROTECTED] wrote:
I added a maven directory to HEAD containing project definitions for all
the artifacts that the normal ant build produces. The main purpose of
this is to capture POM information (project metadata) that allows Derby
to be easily used by other projects that build using maven.
This also allows
[ http://issues.apache.org/jira/browse/DERBY-497?page=all ]
Jeremy Boynes closed DERBY-497:
---
Resolution: Invalid
By default Derby binds just to the localhost address (127.0.0.1) rather than
IN_ANY (0.0.0.0) to restrict access to just being from
David Van Couvering wrote:
Jeremy Boynes wrote:
[snip]
AIUI there are two levels of configuration: system and database
* system configuration comes from system properties and
classloader resources
* database configuration overrides based on values from derby.properties
in the database
David Van Couvering wrote:
Hi, Dan, I've been thinking a lot on what you have to say here. When I
first looked at this, I noticed what the tools and network server were
doing for internationalization, and considered duplicating that approach.
But the original motivation was not just
David Van Couvering wrote:
I'd like to understand the issues and concerns of the size of a common
jar file. Further inspection has shown that pulling in Monitor results
in a large subset of the iapi and impl packages being pulled into the
common area. This will result in a larger footprint
David Van Couvering wrote:
Hi, Jeremy, I like your idea of a revolutionary branch but (a) have no
idea how to set one up and (b) I don't think I have the karma yet to
do it.
a) is easy, just svn copy what you need to a suitable location under
'branches' and merge in your local changes.
I would like to explore the possibility of running multiple Derby
instances in the same JVM, probably in different classloaders.
One use for that is an application server configuration where different
applications may require different versions of Derby or where different
instances may have
I don't remember seeing votes on this from PPMC members so I think this
is premature.
--
Jeremy
Andrew McIntyre wrote:
On 7/2/05, Edward Rayl [EMAIL PROTECTED] wrote:
I have posted final release candidate distributions on my public_html:
http://people.apache.org/~fuzzylogic/derby_10.1/
Andrew McIntyre wrote:
Hello derby-dev,
I have posted final release candidate distributions on my public_html:
http://people.apache.org/~fuzzylogic/derby_10.1/
Tested with Geronimo and J2EE TCK, no problems seen.
+1
--
Jeremy
There seem to be quite a few issues logged against the client
DataSource. Do we want to fix these before releasing 10.1?
My thought is no but wanted to raise the issue.
--
Jeremy
Daniel John Debrunner wrote:
To my mind, with a DataSource connectionAttributes should only be used
for cases where the attribute can not be set as a property, thus their
value should be ignored or overridden by any explict setting.
+1
I would actually go for dropping the
Andrew McIntyre wrote:
Hello derby-dev,
I have posted final release candidate distributions on my public_html:
http://people.apache.org/~fuzzylogic/derby_10.1/
I updated Geronimo to use these jars and switched the client code from
the old IBM driver to the new Derby client. I did not see
Daniel John Debrunner wrote:
Please vote on making Bernt a committer on the Derby project. The
derby-ppmc believe Bernt will be a great benefit to Derby.
[ ] - Add Bernt M. Johnsen [EMAIL PROTECTED] as a Derby committer
+1
--
Jeremy
Daniel John Debrunner wrote:
Please vote on making Øyvind a committer on the Derby project. The
derby-ppmc believe Øyvind will be a great benefit to Derby.
[ ] - Add Øyvind Bakksjø [EMAIL PROTECTED] as a Derby committer
+1
--
Jeremy
I will be there.
David Van Couvering wrote:
Hi, all. I suspect my request for RSVP may have been lost in the high
volume of email on this list, so I thought I would try a more
attention-getting subject.
So far I have confirmed for our lunch at noon on Tuesday June 28 in San
Francisco the
Kathey Marsden wrote:
This morning rather than talking about DERBY-213, Philip and I ended up
talking mostly about running tests.
He had tried to do a baseline derbyAll run and had hit a bunch of
failures. We looked a little at some of the failures and talked about
how some day soon someone
David Van Couvering wrote:
You might want to take a look at DERBY-289 (enable code sharing between
Derby client and engine). Any rearrangement of jar files should
probably take this into consideration.
With the desire to have a single entry on the classpath, I was planning
on including the
Andrew McIntyre wrote:
Based on the feedback so far, I wanted to give a current status as we
head towards a release:
Unresolved issues:
Datasource unification - Jeremy - any update? are you going to try and
get a patch in for this release?
Yes - ETA 6/3 due to coding ban over Memorial Day
Kathey Marsden wrote:
Jeremy Boynes wrote:
Currently we have:
* derby.jar (embedded, engine)
* derbynet.jar (network server)
* derbyclient.jar (network client)
I would like to add derbyserver.jar which includes everything from all
of these to form a complete standalone server; the client
Currently we have:
* derby.jar (embedded, engine)
* derbynet.jar (network server)
* derbyclient.jar (network client)
I would like to add derbyserver.jar which includes everything from all
of these to form a complete standalone server; the client is included so
that people don't need to switch
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Andrew McIntyre wrote:
I'm thinking that in the interests of getting an official release out
with the Derby client, I'd like to aim for a release in about two
weeks or so.
When we're ready - not before :-)
I think we are ready
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
If we rush a release out now and unify later, users see:
10.1 new ClientDataSource and EmbeddedSimpleDataSource
10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
and Embedded
If x = 1.1 or 2 then what we did in 10.1
David's the Geronimo guru on XA.
My understanding is that it is legal for a coordinator to delist a
resource before the end of a transaction and return it to the pool; it
could then be used by another thread (potentially in another
transaction) or just closed.
However, there are many
Andrew McIntyre wrote:
I'm thinking that in the interests of getting an official release out
with the Derby client, I'd like to aim for a release in about two
weeks or so.
When we're ready - not before :-)
- Jeremy, in what timeframe do you think you will have a working
prototype for the
Kathey Marsden wrote:
Satheesh filed DERBY-310 to manage this issue, but to clarify
direction, I thought it worthwhile to submit this to vote:
There are some differences in behaviour when using the client vs the
embedded driver. Examples are DERBY-211 and DERBY-254. Other
differences are
Satheesh Bandaram wrote:
Actually 'retrieveMessageText' property would only apply to Derby
client. So is '*securityMechanism*' and tracing properties. Embedded
driver doesn't have the tracing mechanism that is part of Derby client.
I think retrieveMessageText and trace apply to both.
The
Kathey Marsden wrote:
o Some sort of automatic connection thread management for Network
Server.
Currently for network server the Connection Threads are created
on demand and recycled,
but never reclaimed if the load is low.
How about an abstraction for thread management
Daniel John Debrunner wrote:
Early implementation is one thing, but you want to get the public
interfaces right, or at least easily extensible, from the start so you
don't end up regretting something forever.
True, but in this case the public api is defined by class name(s) (that
implements
Reporter: Jeremy Boynes
An attempt to connect to a network database with create=true results in an
exception if the database exists; with the embedded server a warning is raised.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
Daniel John Debrunner wrote:
Though maybe the internal re-work could be separated into a follow on
project, a common data source api could still use the current internal
mechanism.
That's what I would do for an initial impl.
I think the only question is
whether they are a good idea or not: if
Summary of a quick chat Kathey and I had on IRC
Regarding the format of the Reference returned from Referencable, talked
about switching from the one-RefAddr-per-DS-property model to one with
all of the properties encoded into one RefAddr so that multiple
locations could be supported.
Kathey Marsden wrote:
Jeremy could you comment on the changes that you made to
ClientDataSource? Is there follow up work that you still need to do
there for the release?
r168355 | jboynes | 2005-05-05 10:00:08 -0700 (Thu, 05 May 2005) | 1 line
move all generic implementation into
Given the email delays, I opened an IRC channel for Derby discussion:
IRC://irc.freenode.net/#derby
It will at least allow communication with a 6 hour lag time :-(
--
Jeremy
[
http://issues.apache.org/jira/browse/DERBY-287?page=comments#action_65395 ]
Jeremy Boynes commented on DERBY-287:
-
Please can you also include the clarification for triggers.
Return value of IDENTITY_VAL_LOCAL for different connections
Myrna van Lunteren wrote:
I could be missing something here...
Explicit details about a fix should go into the bug tracking system.
Users should be able to search for a problem find out what was done
without having to download svn the source tree.
Agreed.
Use Jira for recording information about
Dibyendu Majumdar wrote:
I think that building a unified DataSource API will actually not help
very much because the problem is that there is no standard interface for a
DataSource anyway.
However, there is a common configuration model, that of a JavaBean. This
is easy to map to a GUI for
Daniel John Debrunner wrote:
I wasn't talking about that DataSource, but a possible optimisation
where a Java Bean (as you call it, I was using 'DataSource (like)' :-)
:-)
could be pre-populated for the common connection requests, to avoid
having to create a new Java Bean object each time. With
Dibyendu Majumdar wrote:
From: Jeremy Boynes [EMAIL PROTECTED]
The advantage of a unified model is that there is only one
implementation *within Derby.* Having multiple ones for one product
depending on the JVM and transport in use is just confusing.
I think another problem with a unified
Daniel John Debrunner wrote:
It's an interesting idea but the details may make it not possible, for
example References don't exist in J2ME.
Also since in the most case applications do not use Derby's or any
DataSource implementation classes directly, I don't see how such a
change would affect
Lance J. Andersen wrote:
The reality is that there are way too many applications which utilize
java.sql.Driver implementations to depecrate this functionality.
We are in JDBC 4 reducing the boiler plate code by having
DriverManager.getConnection() utilize the Server Provider Mechanism in
J2SE
Sunitha Kambhampati wrote:
maybe because you are missing the jakarta-oro-2.0.8.jar in your
classpath .. ?
Doh - thanks.
--
Jeremy
David Van Couvering wrote:
Hi ,all. I am getting questions we could use Derby inside a container
such that each application in the container could have its own separate
configuration. In particular, it would be nice if each application
(which often has its own classloader) could store its
TomohitoNakayama wrote:
Hello.
I have execused svn updated ,
but code for derbynetclientmats seems not updated.
I will check building.
There may be mistake especially where around sane option...
derbynetclientmats was passing for me last night. Did you remember to
add the new derbyclient.jar to
Satheesh Bandaram wrote:
I suspect the class hierarchy has been made this way partly to match
Embedded driver. I am still thinking why the Embedded driver does this..
I don't know if it is relevant but most of the implementation in the
client code uses ClientDataSource instances rather than the
Last couple of times I have run this suite I am getting reports like the
one attached that show no tests passed and no tests failed. If I look at
the individual tests they all passed.
Any ideas?
--
Jeremy
Generating report for RunSuite derbynetclientmats null null DerbyNetClient
true
Satheesh Bandaram wrote:
I think the ClientBaseDataSource was not meant to be a public class. We
tried to localize all public classes into the 'jdbc' package and use
only the jdbc package to generate public javadoc. That is one of the
reasons for putting all public tracing support in
Kathey Marsden wrote:
Jeremy Boynes wrote:
I am going to go through the client code and switch the usages to the
base class (which declares the methods being used) and then change the
hierarchy here as proposed.
Hi Jeremy,
I would vote -1 on the restructuring on the basis that I think that we
Kathey Marsden wrote:
Ultimately, this will allow us to have references that point to
multiple addresses (e.g. in a federated server)
Just some questions. Not educated enough in this area to comment yet #:)
Could you explain the federated scenario in more detail and how the
referenceable
Mamta Satoor wrote:
How about if we(Jeremy) format the 10.0 branch too :)
Easily done if so desired.
--
Jeremy
Patch applied as revision 167863
After applying this I saw one additional error in the derbynetclientmats
testsuite:
*** Start: dataSourcePermissions_net jdk1.4.2_07 DerbyNetClient
derbynetmats:derbynetmats 2005-05-02 21:58:40 ***
25a26
org.apache.derby.iapi.services.context.ShutdownException:
[
http://issues.apache.org/jira/browse/DERBY-250?page=comments#action_64340 ]
Jeremy Boynes commented on DERBY-250:
-
Applied Kathey's patch
Sendingjava\client\org\apache\derby\client\am\CrossConverters.java
Sendingjava\client\org
Shreyas Kaushik wrote:
When there is a call to DataSource's getConnection() method, this will
happen on the framework's/app server's DataSource. If the underlying
DataSource is a XADataSource, a call to getConnection() method gives
out a XAConnection. This is wrapped as java.sql.Connection
Kathey Marsden wrote:
Thanks Jeremy,
I don't see this failure and am not sure how the setObject changes could
have impacted this test. Maybe it's an intermittent failure we need to
look at.
It could be - I see we have a different JVM level and I was also
disconnected from the network when I
Kathey Marsden wrote:
Jeremy Boynes wrote:
I attached derby.log if it is of any use.
The trace be in the dataSourcePermissions_net.tmp file in the test
output directory.
Even if there is not a trace the tmp file should give us an idea of how
far it got before things went south.
I reran
Mike Matrigali wrote:
I know it is a horrible discussion, but before you reformat all the
code I would like to know what you are reformatting it to. I haven't
used the tool you used, so the settings you posted did not mean much
to me.
I'd suggest looking at the reformatted client code but its
I was intrigued by the implementation of Referenceable in the client
DataSource impl - it uses the address entries in the reference to store
the properties of the connection.
I may be misunderstanding this but I thought address fields in a
Reference were used to store multiple potential
Kathey Marsden wrote:
Jeremy Boynes wrote:
Done as of rev 165585.
--
Hi Jeremy,
Could you tell me what you ran it through. I wanted to run the same
thing on my pending client patch.
I used IntelliJ IDEA with the attached layout template (which is a bit
heavier than I usually use but I wanted
The class hierarchy the client DataSources is:
ClientBaseDataSource
|
+-- ClientDataSource
|
+-- ClientXADataSource
|
+-- ClientConnectionPoolDataSource
The three standard interfaces DataSource, ConnectionPoolDataSource and
XADataSource are not related to each
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
The class hierarchy the client DataSources is:
ClientBaseDataSource
|
+-- ClientDataSource
|
+-- ClientXADataSource
|
+-- ClientConnectionPoolDataSource
The three standard interfaces DataSource
Kathey Marsden wrote:
Hey, thanks I think I will take you up on that. It was the patch I sent
to the list last week for DERBY-250.
Dan said he didn't have any additional issues with it, so I think it is
ready to go in.
OK
I better get my paintbrush fixed up so my patches match our new shed.
I am
David Van Couvering wrote:
I was looking to see if ++ was atomic (as I suspected it's not) and I
found this very interesting article from the Blue Guys about
java.util.concurrent.atomic in JDK 1.5. I am not an expert in locking,
but this looked very interesting. Has anybody looked at this?
David Van Couvering wrote:
Also, the JavaBean approach assumes you create an instance of the beast,
and I have noticed that many command-line classes have most of their
code in static methods and use static variables (not that they should,
but that's what they do). Also, it might actually be
I would like to raise the issue of using 3rd party libraries with Derby.
For example, in another thread we are talking about command line
interfaces. Traditionally Derby has implemented all its own parsing for
this included in the main or tool jar. A lot of other Apache projects
use commons-cli
Daniel John Debrunner wrote:
Edward Rayl wrote:
I think any proposed changes should be invisible to the developer using
Derby. Therefore I think alternatives A or D make the most sense. I
would only choose D if the perceived benefit justifies it.
a) stick with what is done now and use our own
Lance J. Andersen wrote:
There is also an issue on windows of a classpath size. I know i have
been burnt by this before.
I think most projects of any size, commercial or open source, have moved
away from using raw CLASSPATH and use custom classloading.
For example, a common technique is to
Kathey Marsden wrote:
David Van Couvering wrote:
We could add an argument that indicates whether or not the main
program should call System.exit() or just return. It's very valuable
to have a non-zero exit status when calling a command from the
command-line, for better scriptability...
e.g.
1 - 100 of 196 matches
Mail list logo
