<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
<title>David Van Couvering &apos;s Blog</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/" />
<modified>2008-05-09T17:07:54Z</modified>
<tagline></tagline>
<id>tag:weblogs.java.net,2008:/blog/davidvc//274</id>
<generator url="http://www.movabletype.org/" version="3.01D">Movable Type</generator>
<copyright>Copyright (c) 2008, davidvc</copyright>
<entry>
<title>Internet content by reference, not by value</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2008/05/internet_conten.html" />
<modified>2008-05-09T17:07:54Z</modified>
<issued>2008-05-09T17:07:48Z</issued>
<id>tag:weblogs.java.net,2008:/blog/davidvc//274.9765</id>
<created>2008-05-09T17:07:48Z</created>
<summary type="text/plain">It&apos;s time to apply the DRY (Don&apos;t Repeat Yourself) principle to web data</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
<i>Note: if we had DRY working for blogs, then I could have just embedded the content from <a href="http://davidvancouvering.blogspot.com/2008/05/internet-content-by-reference-not-by.html">
my other blog</a> and not have had to enter things in twice.  Posting a link is not the same as having the content immediately available, which is why I decided to just copy the blog.  Oh well...</i>
<p>
You may have noticed that I am very interested in how data is managed on the Internet as a platform, at a web scale.  In that light, I have been having some very illuminating and interesting conversations with an old friend and colleague, <a href="http://tagschema.com/blogs/tagschema/">Nitin Borwankar</a>. His thoughts on  <a href="http://gigaom.com/2008/02/06/data-property-rights-not-portability/">data property rights</a> and <a href="http://tagschema.com/blogs/tagschema/2008/05/how-many-times-do-i-have-to-tell-you.html">DRY data</a> are concepts that if implemented could result in a major shift in how we manage data on the web.
<p>
Data property rights is about laying out a "bill of rights" for data that goes far beyond "the right to move".  It also includes the right to access, modify, remove and own <span style="font-weight: bold;">your</span> data.  So often it happens that once you upload your content to a site, you no longer have full rights to that content, as if somehow in the act of uploading it it is no longer yours.  It's like living in a serfdom where you do all the work to plow, seed, tend and harvest the land, but the fruit of your labor is not yours, just because you are using the land that someone else owns.
<p>
DRY data is about following the principle of <a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself">Don't Repeat Yourself</a> for web content.  Web applications need to start applying this principle, so that rather than you having to load copies of your content across multiple sites (and often losing some degree of ownership of it in the process),  you place it in one location (your "home" on the Web, as it were), and then you refer application providers to that one place.  They can focus on providing added value (for instance, referring it to your friends, enabling collaboration, or helping you organize it or present it in useful ways) rather than on the overhead of building and deploying a scalable storage architecture.
<p>
Nitin calls this architecture YINAS (YINAS Is Not A Silo).
<p>
<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://nelson.textdrive.com/~nitinb/images/yinaspattern.jpg"><img style="cursor:pointer; cursor:hand;width: 400px;" src="http://nelson.textdrive.com/~nitinb/images/yinaspattern.jpg" border="0" alt="" /></a>
<p>
The value of DRY for the user is obvious - I only have to put my stuff in one place, and I get to really own my stuff, rather than the vendor owning it.  DRY is also very valuable for the vendor, as they can save overhead and complexity by delegating the work of scalable storage and indexing to a "data service provider" rather than having to do it themselves.  It's even good for the environment, because you need fewer disk farms sucking up power and space.  
<p>
It's funny, it makes so much sense, but nobody is really doing this.
<p>
I pulled <a href="http://www.tbray.org/ongoing/">Tim Bray</a> aside at Java One to talk to him about these ideas after reading <a href="http://www.tbray.org/ongoing/When/200x/2008/05/05/Changing-Your-Address">his blog about changing his address</a>, and he suggested that concepts are good, but a simple <span style="font-weight: bold;">proof</span> of concept is better.   Hm... let me think about that ... :)
]]>

</content>
</entry>
<entry>
<title>You can help with NetBeans database tooling</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/10/you_can_help_wi.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-10-18T22:46:57Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.8452</id>
<created>2007-10-18T22:46:57Z</created>
<summary type="text/plain">I&apos;ve put together a quick survey so you can tell us which way to go with NetBeans database tooling...</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
<img alt="survey.jpg" src="http://weblogs.java.net/blog/davidvc/archive/survey.jpg" width="200" height="300" />
<p>
I know this isn't my main blog page any more (I'm hanging out at <a href="http://davidvancouvering.blogspot.com">http://davidvancouvering.blogspot.com</a>),
but I wanted to reach out to you all and get your input.
<p>
We are looking at what we want to do next with database tooling in NetBeans, and there are some features I'm just not sure how important they are.  You can help guide the ship in the right way.
<p>
I have put together a <a href="http://freeonlinesurveys.com/rendersurvey.asp?sid=jbk4vr915xv9qr0350286">
very quick survey</a>, no more than ten minutes.  If you're so inspired, please check it out. 
<p>]]>

</content>
</entry>
<entry>
<title>Moving to new digs</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/moving_to_new_d.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-27T09:19:33Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7746</id>
<created>2007-06-27T09:19:33Z</created>
<summary type="text/plain">I&apos;m moving my blog to a new location...</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
I've decided to move my blog to a new location.  You can now find me at <a href="http://davidvancouvering.blogspot.com">http://davidvancouvering.blogspot.com</a>.
<p>
Why am I making the move?  Well, this was a hard decision.  I really like the java.net community, and I like how the editor takes care to call out cool and interesting stuff.
<p>
But the problem is, sometimes I want to talk about more than Java, and more than my work.  And java.net really wants and needs to stay focused on Java technology and things that impact Java (like Ruby).  If my blog waxes poetic about politics or the cutest thing my kid did the other day, it tends to diffuse the focus of this site.  People come here for serious Java stuff.
<p>
I also am a little constrained by the fairly rigid walls of java.net as a blogging platform.  Personally, I'm tired of typing in raw HTML.  I want to have a few widgets, not many, on my page.  I want Google Reader to show the whole post, not just the blurb.  Things like that.
<p>
If you don't want to see cute pictures from time to time, or hear about my opinions on education, and you can <a href=
http://davidvancouvering.blogspot.com/search/label/technology">subscribe just to the "technology" label</a>.  There's also a <a href="http://davidvancouvering.blogspot.com/search/label/quicklink">quicklink label</a>, for useful delicious links that I have auto-posted to my blog.
<p>
So, see you at my new digs!
<p>
P.S. Yes those are probably the dullest photos on my "recent Flickr Photos" widget.  But I promise they'll change from time to time :)  (Most of you will probably be reading my through an aggregator anyway and won't even see my fun widgets.  Too bad...)]]>

</content>
</entry>
<entry>
<title>Replication?  In Java DB?  Wow.</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/replication_in.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-22T21:46:58Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7716</id>
<created>2007-06-22T21:46:58Z</created>
<summary type="text/plain">Just found out that Egil Sorensen, a student at NTNU in Trondheim, has contributed his thesis work - replication and hot standby for Apache Derby - to the Derby community.</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
Open source continues to amaze me.  For so many years, I have worked on projects where customers would clamor for features, and we just didn't have enough time in the day or people to get them all built.  We would say "yeah, that sounds cool" but with all the other things on our plate, when would we ever get to it?
<p>
Well, in open source, it's a whole different ball game.  The latest example is the <a href="https://issues.apache.org/jira/browse/DERBY-2852">contribution of Egil Sorensen's master's thesis</a>.  Egil is a student in the Computer Science department at NTNU in Trondheim, Norway, and he has contributed code that provides replication and hot standby for Apache Derby (discovered through <a href="http://weblogs.java.net/blog/mortazavi/archive/2007/06/thesis_work_wit.html">Max Mortazavi's blog</a>).
<p>
<i>
This paper and attached source code describes the work done to add hot standby replication functionality to the Apache Derby Database Management System.
<p>
By implementing a hot standby scheme in Apache Derby several features are added. The contents of the database is replicated at run time to another site providing online runtime backup. As the hot standby takes over on faults availability is added in that a client can connect to the hot standby after a crash. Thus the crash is masked from the clients. In addition to this, online upgrades of software and hardware can be done by taking down one database at the time. Then when
the upgrade is completed the upgraded server is synchronized and back online with no downtime.
<p>
A fully functional prototype of the Apache Derby hot standby scheme has been created in this project using logical logs, fail-fast takeovers and logical catchups after an internal up-to-crash recovery and reconnection.
<p>
</i>
<p>
In case you missed that, this feature provides basic high availability to Derby.  This is not small potatoes, and it was done as an independent contribution to Derby.  Wow.
]]>

</content>
</entry>
<entry>
<title>Derby 10.3 Beta Available</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/derby_103_beta.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-22T19:02:41Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7715</id>
<created>2007-06-22T19:02:41Z</created>
<summary type="text/plain">A quick announcement that Derby 10.3 is in beta. </summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
Derby 10.3 beta <a href="http://people.apache.org/~myrnavl/10.3.1.0.beta/">
is available for testing</a>.  If you are using Derby/Java DB, you should try  your local tests with this beta and make sure everything's working for you.
<p>
<a href="http://wiki.apache.org/db-derby/DerbyTenThreeRelease">This page</a> describes what's in this release.  Of note are security improvements, performance improvements, and the ability to drop or rename a column using ALTER TABLE.  And, as usual, a slew of bugfixes.
<p>
One thing to be aware of is that the Network Server starts with a security manager installed by default now.  This is a good thing as it provides you, by default, strong protection from potentially malicious Java code running in your server.  
<p>
But what this also means is that if you have Java procedures installed in your database that do funny things like file I/O or open network sockets, you may get exceptions saying you don't have permissions to do this.  You can fix this by modifying the security policy file to grant permissions, or by disabling the security manager by running the Network Server with the -noSecurityManager option.]]>

</content>
</entry>
<entry>
<title>Spam Vegetable Strudel</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/spam_vegetable.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-22T01:10:36Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7707</id>
<created>2007-06-22T01:10:36Z</created>
<summary type="text/plain">GMail context sensitive links provoke a smile when looking at spam.</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
I noticed today that I had 754 messages in my Spam folder in Gmail.
<p>
I decided to open the folder, and GMail had decided to place the following sponsored link at the top of the folder:
<p>
"Spam Vegetable Strudel - Bake 20 minutes or until golden, serve with soy sauce"
<p>
I just did a refresh, and now it says "Spam Imperial Tortilla Sandwiches - To serve, cut each roll in half"
<p>
Yum, yum.  Another reason to avoid my spam folder]]>

</content>
</entry>
<entry>
<title>Legal Blogging</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/legal_blogging.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-21T00:47:42Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7699</id>
<created>2007-06-21T00:47:42Z</created>
<summary type="text/plain">Sun&apos;s General Counsel blogs.  Every now and then he produces a gem that is a real eye opener.</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
I am a techie, and generally am not interested in the legal world.  That changed a bit when I got into open source, where just to be able to contribute code you have to have some pretty solid understanding of open source licenses.
<p>
I wasn't sure what to think when I heard Sun's general counsel, Mike Dillon, had <a href="http://blogs.sun.com/dillon/">started a blog</a>.  What the heck, I thought, I'll subscribe
<p>
He doesn't blog very often, but when he does, it can be a real eye opener for me.  His latest one <a href="http://blogs.sun.com/dillon/entry/on_litigation_azul">on litigation</a> is just great.  It has just the right level of detail for a layman like me, it educates, and it makes a point: <i>... it's important to remember that litigation is just a tool. And, as with all tools, it is effective only when used dispassionately, in the right way and for the right reasons.</i>
<p>
Thanks, Mike, and keep it up!]]>

</content>
</entry>
<entry>
<title>Java DB Authorization using GRANT and REVOKE</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/working_on_auth.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-18T03:23:01Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7657</id>
<created>2007-06-18T03:23:01Z</created>
<summary type="text/plain">A quick tip on how to enable fine-grained access control in Java DB using SQL GRANT and REVOKE.</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
The default behavior of Java DB is that you have two level of access control: full access and read-only.  Again, this is I believe due to the legacy of Cloudscape being originally an embedded-only database.  In this environment, the embedding application is responsible for controlling access to the database, and always only logs in as one user, so there is no real need for finer-grained access control in the database
<p>
But that changes when you have a client/server environment.  So as of 10.2, Java DB has support for the SQL standard GRANT/REVOKE.  However, again for backward compatibility, you have to explicitly enable support for it, otherwise you get the default behavior that anybody who is able to log in has full access.
<p>
You enable GRANT/REVOKE access control by adding an entry in your <code>derby.properties</b> file:
<p>
<pre>
derby.database.sqlAuthorization=true
</pre>
<p>
Once you have done this, only the owner of a resource (such as a table, view, index, etc.) has any rights to view, modify, or delete the resource.  The owner is the one who created the resource.
<p>
The owner can then grant and revoke specific rights for that resource to other users.  The rights supported by Java DB are: DELETE, EXECUTE, INSERT, SELECT, REFERENCES, TRIGGER, UPDATE.  For more information on SQL authorization using GRANT and REVOKE, you can <a href="http://db.apache.org/derby/docs/10.2/devguide/cdevcsecuregrantrevokeaccess.html">check out the Derby documentation</a>
<p>
So, for example, lets say you create a table named "races".  You can then let the Marx Brothers see the races by executing the following command:
<p>
<pre>
GRANT SELECT ON TABLE races TO groucho, harpo, chico
</pre>
<p>


]]>

</content>
</entry>
<entry>
<title>No More Java DB Password in The Clear</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/no_more_java_db.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-16T00:21:20Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7662</id>
<created>2007-06-16T00:21:20Z</created>
<summary type="text/plain">This blog tells you how to configure the Java DB client so it doesn&apos;t send the password in the clear</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
As I mentioned in my previous blog, Java DB's legacy is in the embedded world, where there is no such thing as sending the password over the wire.
<p>
But when you introduce the network client, this becomes an issue.  And sending users and passwords in the clear is just not acceptable.  So this blog tells you how to stop that from happening.
<p>
Java DB allows you to configure how credentials are sent to the server using four different modes, <a href="http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclientsecurity.html">
documented here.</a> and <a href="http://db.apache.org/derby/docs/10.2/adminguide/cadminapps49914.html">here</a>.
<ul>
<li>CLEAR_TEXT_PASSWORD_SECURITY (0x03) - User and password are sent in the clear.  This is the default
<li>USER_ONLY_SECURITY (0x04) - <b>Only</b> the user is sent.  This doesn't work if authentication is enabled on the server
<li>STRONG_PASSWORD_SUBSTITUTE_SECURITY (0x08) - "When using this mechanism, a strong password substitute is generated and used to authenticate the user with the network server. The original password is never sent in any form across the network." (from the docs)
<li>ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x09) - The user and password are encrypted using a pluggable encryption mechanism
</ul>
<p>
Now, why on earth am I including the hex value for the security mechanism here?  Because (and I kid you not), when you specify the security mechanism you want to use on your URL, you have to pass the numeric value for the mechanism, <b>not</b> the name.
<p>
Needless to say, when I discovered this, <a href="https://issues.apache.org/jira/browse/DERBY-2833">I immediately logged a bug</a>.  It didn't help that <a href="https://issues.apache.org/jira/browse/DERBY-2834">nowhere do the docs actually tell you you need to do this</a>.  I had to figure this out through a series of experiments and failures.
<p>
And get this, you have to convert the hex value to an integer, if you pass in 0x08 you get a NumberFormatException.  Sweet.  
<p>
Anyway, I'm here to help.  If you want security, you probably want to choose STRONG_PASSWORD_SUBSTITUTE or ENCRYPTED_USER_AND_PASSWORD.  I personally don't know the difference in terms of strength/breakability, but I do know that if you choose ENCRYPTED_USER_AND_PASSWORD, then you <b>also</b> need to <a href="http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html">install IBM JCE and configure the JRE to use an appropriate security provider</a>.  You have to do this for the JRE used by both the client and the server.  If you are deploying your client to a wide swath of machines, this particular approach is not feasible, as far as I can tell.  I am pinging the Derby user group about this, more info will be posted here if I get it.
<p>
So, personally, I'm opting for STRONG_PASSWORD_SUBSTITUTE (or 8 if you're thinking in integers).  Here's how you do it:
<p>
First, if you want to <b>enforce</b> that only this security mechanism be used, you can configure the network server by putting this line in derby.properties:
<pre>
derby.drda.securityMechanism=STRONG_PASSWORD_SUBSTITUTE_SECURITY
</pre>
<p>
Next, when you connect, include the securityMechanism property in your URL, e.g
<pre>
jdbc:derby://localhost:1527/mydb;create=true;securityMechanism=8
</pre>
<p>
Now your password is no longer flying over the wire in the clear.
<p>
<b>UPDATE:</b> After some discussion on the derby-user list, I have some more clarity about securing your network pipe. 
<p>
First of all, the reason you can't use Sun's Java runtime to do password encryption with Java DB is because Java DB network communication uses <a href="http://en.wikipedia.org/wiki/DRDA">DRDA</a>, a standard network protocol (used primarily by IBM).  DRDA's encryption protocol uses a 256-bit key, which is considered too short (and thus too weak) by Sun's encryption engine.  IBM JCE does support a 256-bit key, so that's why you would need to install it.  I have asked if there other encryption engines that support a 256-bit key.
<p>
The STRONG_PASSWORD_SUBSTITUTE mechanism I describe above was implemented as an alternative because standard encryption has these issues with support and configuration overhead.
<p>
There was also general agreement on the list that what you <b>really</b> want is encryption using industry-standard SSL (or its new incarnation, TLS).  Java DB 10.3, which is getting ready to be released, will include support for SSL/TLS.  Using this mechanism is recommended unless you are concerned about the performance impact of encrypting all communications and you are fine with just protecting the password. ]]>

</content>
</entry>
<entry>
<title>Authentication and Authorization with the Java DB Network Server</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/authentication_1.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-15T23:44:39Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7658</id>
<created>2007-06-15T23:44:39Z</created>
<summary type="text/plain">Some tips on how to make your Derby network server more secure</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
The original Cloudscape was built as an embedded-only database -- that is, it could only run inside the VM of another application.  It did not have a client/server mode.  That was added later.
<p>
In some areas, Java DB continues to carry have this embedded "legacy" with it.  One particular area you should be aware of is authentication and authorization.  
<p>
By default when you start up the Java DB Network Server, it accepts connections on localhost only [1], but it allows <b>any</b> user/password combination, and it allows any user to do anything they darn well please.  And on the client, by default, the user and password are sent in the clear.  
<p>
If you don't like this (and you shouldn't if you are running Java DB with sensitive data and/or or listening on ports other than localhost), there are some things you can do (NOTE: I'm assuming you're using Java DB 10.2 or greater):
<p>
<ul>
<li>Enable authentication on the server
<li>Configure the client to <b>not</b> send the password in the clear
<li>Control access and privileges using GRANT/REVOKE
</ul>
<p>
In this blog I'll talk about how to enable authentication on the server.  In subsequent blogs I'll talk about configuring the client to not send the password in the clear, and how to use GRANT/REVOKE.]]>
<![CDATA[<p>
First of all, you need to tell Java DB that you want to actually authenticate users.  You do this by setting the system property (on the command line or in <code>derby.properties</code> [1]):
<p>
<pre>
derby.connection.requireAuthentication=true
</pre>
<p>
<p>
Java DB authentication is pluggable - you can use LDAP, builtin authentication, or authentication driven by a user program.  For more information, see <a href="http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure42374.html">
the Derby manual section on authentication</a>
<p>
The simplest solution is to use <a href="http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure21547.html#cdevcsecure21547">
builtin authentication</a> for all your databases, and I'll describe how to do that here.  
<p>
You basically enter in a series of users and passwords in to derby.properties (this means, of course, that you need to set up proper permissions on the <code>derby.properties</code> file)
<p>
<pre>
# Enable builtin authentication
derby.authentication.provider=BUILTIN

# Define users and passwords.  User names and passwors
# are *case sensitive* and can be quoted if desired
derby.user.groucho=cigar
derby.user.harpo=toottoot
derby.user.chico=sanityclause
</pre>
<p>
Now when you try to connect with any old user or password, you will be pleasantly foiled.
<p>
More on authentication and authorization in upcoming blogs.  I thought it better to do them in simple pieces so you're not overwhelmed by too much information in a single blog.
<p>
[1] If you want to listen on a different host or port, use <code>derby.drda.host</code> and <code>derby.drda.portNumber</code> in your <code>derby.properties file
<p>
[2] If you're wondering where you should put derby.properties: by default it is in the directory where you start the server or the VM that embeds the server.  You can change this by setting the system directory, e.g. 
<pre>
java -Dderby.system.home=/export/home/groucho/movies derbyrun.jar server start
</pre>
]]>
</content>
</entry>
<entry>
<title>Searching the Derby Manuals</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/searching_the_d.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-15T18:33:15Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7655</id>
<created>2007-06-15T18:33:15Z</created>
<summary type="text/plain">The current Derby manuals are not well indexed and sometimes it is hard to find things.  Here is a quick helpful tip</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
A common complaint about learning Derby is "I can't figure out where in the manuals it talks about how you do 'X'".  As much as I whine about Google's desire for all our data, they do have an excellent search engine, and you can apply it to help you here.
<p>
Someone recently asked on the mailing list how to do this, and Oystein Grovlen gave this very helpful response:
<p>
<i>
I agree that the documentation is difficult to navigate in.  An common
index for all manuals would have helped a lot. Now, it is not always
clear which manual to look in.  I often end up using Google to search
the manuals.  If I add "site:db.apache.org/derby/docs/10.2" to my Google
search criteria, I will only search the 10.2 manuals.
</i>
<p>
I have used this approach and it has helped me a lot, both for myself and when I'm trying to answer user questions.
]]>

</content>
</entry>
<entry>
<title>Has Google let the genie out of the bottle?</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/has_google_let.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-14T20:40:55Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7639</id>
<created>2007-06-14T20:40:55Z</created>
<summary type="text/plain">Local storage on client machines, peer-to-peer collaboration: who needs Google?</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
I think we all know this: Google Loves Data.  They want all of our data, every last bit of it.  They live for data.  They want to touch it, caress it, sift it, search it, organize it, categorize it, and monetize it.  They are building data center after data center to store and serve it all.
<p>
Let's just assume I'm right here.  And let's assume some of us don't really want all our data on Google, and <a href="http://www.privacyinternational.org/article.shtml?cmd[347]=x-347-553961">
don't fully trust Google</a>.
<p>
Enter Google Gears (and similar solutions like Java DB).  Let's assume that client-side storage gets very popular, and everyone now a local database on their machine.  Combine this with iTunes, which comes with <a href="http://developer.apple.com/networking/bonjour/">
Bonjour</a>, which uses <a href="http://www.dns-sd.org/">
DNS Service Discovery</a>, an IETF standard DNS-based auto-discovery service.  
<p>
The consequences haven't escaped me, nor have they escaped <a href="http://www.meshverse.com/2007/05/31/gear-mesh-power-to-the-peers/">
Laurence Rozier</a> or <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=207783">Frank Sommers</a>
<p>
These are enabling technologies on a majority of people's machines that would allow people to build and use massive, secure, Internet-based data collaboration applications and services without <b>ever</b> putting a single byte of their data on Google's servers.  
<p>
Ouch.]]>

</content>
</entry>
<entry>
<title>Some thoughts about Google Gears</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/some_thoughts_a.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-14T20:24:29Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7638</id>
<created>2007-06-14T20:24:29Z</created>
<summary type="text/plain">I&apos;ve had some time to chew over Google Gears and how this impacts the world of Internet client architectures, and here are some initial thoughts...</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[I've been thinking about Google Gears.  As I <a href="http://weblogs.java.net/blog/davidvc/archive/2007/05/google_gears_th.html">
mentioned</a>, I think it's a pretty solid technology and solves a real problem in a real way (and it doesn't hurt that it comes from Google and is open source with a BSD license).
<p>
But it all depends on where you are coming from.  <a href="http://weblogs.java.net/blog/javakiddy/archive/2007/06/a_rose_by_any_o.html">
Simon Morris crystallized my thinking around this</a>.  If you are a Browserist, or even if you're not but you need to build a browser-based solution because your boss or your market tells you you have to, then Google Gears is a very good fit.
<p>
But if you're a Neo-Desktopian, then all you really need is the ability to store data in the client.  But you need this in a way where your desktop application "can float free of a physical local client installation, deploying on demand just like web pages" (to quote Simon).  Traditional databases like MySQL and Oracle just don't cut it here. SQLite can fit in this space, and that's why it's not surprising to me that Adobe AIR (previously known as Apollo) has chosen to include it.
<p>
If you are using Java (and Java Web Start) as your deployment technology of choice, and I personally like this very much, and I think it's going to get better, then Java DB is an excellent choice for your client side storage.  
<p>
Others may choose Berkeley DB for Java, as it is lighter weight. But when I mention this choice to people I regularly get two questions: "but isn't that controlled by Oracle?" and "don't I have to pay to distribute this if my application is not open source?"  Um, yes, and yes, and that is a problem, I have to admit.  Dual-licensed open source technologies controlled by a single company are definitely barriers to adoption IMHO.
<p>
If you're using client-side storage for offline support (versus just say caching local state), then you also need a synchronization solution that works over the Internet.  I <a href="http://weblogs.java.net/pub/a/today/2007/01/16/synchronizing-web-client-database.html">
wrote about how you might do this</a>, and I'm sure others, like Zimbra, are solving this too.  But you don't need all the fancy shmancy page caching and synch technology that Google Gears comes with because your application is self-contained and not served up off of the web.
<p>
So, although Google Gears is cool and definitely has legs (mostly because it comes from Google), it is not a fit for all situations.
]]>

</content>
</entry>
<entry>
<title>Gems from Database Users</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/gems_from_datab.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-05T20:12:06Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7569</id>
<created>2007-06-05T20:12:06Z</created>
<summary type="text/plain">I got a lot of great responses from folks wanting to help out with NetBeans database tooling.  A couple of comments I just have to share with you...</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
A number of folks responded (some in comments) to my <a href="http://weblogs.java.net/blog/davidvc/archive/2007/06/looking_for_a_f.html">request for folks interested in participating in a series of interviews</a>.
<p>
A few of the responses were so funny/delightful that I have to share them here.  Names have been removed to protect the innocent.
<p>
<i>
We are currently using ER-Win to build our database schema. I don't know
if you have ever used it, but I think it is both craptastic AND
sucktacular.
<p>
<hr>
<p>
I'm have not been the main "DB Guy" on projects for several years, and
Back In The Day, our ER Diagraming Tool was made of plastic for hard
copy, or a white board for soft copy  :-) .
<hr>
<p>
</i>
From a veteran with 23 years in the industry:
<i>
<p>
I went from an ISAM based system (no,
not BTrieve -- it was based on an Alpha Micro (Alpha who??)) straight in
to Informix, and from there to Oracle. I heard an anecdote about some
"yahoo" criticizing my Informix DB Schema of the day, saying "it wasn't
relational". His argument was that since I didn't have any foreign keys,
and thus no RI, it couldn't have been a relational database. Mind,
Informix was, of course, an RDBMS. But also, when I was working on it --
we didn't HAVE foreign keys. They came later, and we weren't about to
retrofit them into the schema. *snort* Kids!
<p>
<hr>
</i>
Who said working on databases couldn't be fun?  Thanks, guys, for the good laughs and good humor.]]>

</content>
</entry>
<entry>
<title>Talking Engineerese</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/davidvc/archive/2007/06/talking_enginee.html" />
<modified>2008-02-13T18:05:55Z</modified>
<issued>2007-06-05T20:11:21Z</issued>
<id>tag:weblogs.java.net,2007:/blog/davidvc//274.7570</id>
<created>2007-06-05T20:11:21Z</created>
<summary type="text/plain">My brother is in the sad situation of having to work with engineers like me and trying to make sense of their (our) way of speaking.  He posted an actual IM transcript that just makes your hair curl.</summary>
<author>
<name>davidvc</name>

<email>david.vancouvering@sun.com</email>
</author>

<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/davidvc/">
<![CDATA[<p>
I was talking with my brother on IM last night and he complained about sotware engineers.  He showed me a conversation between himself and an engineer.  I thought it was a made-up joke dialog, to make his point.
<p>
But he <a href="http://www.namesatwork.com/blog/2007/06/04/talking-to-techies-culture-clash/">
blogged about it today</a>, and said it was an <b>actual transcript</b>.  OMG!  Here it is in its full glory.  Read it and weep.
<p>
<i>
AVC - (presenting plan and budget) Can you do this?<br>
AB - Absolutely<br>
AVC - Can you get it done by the due date?<br>
AB - Yep<br>
AVC - Can we get it done using this budget?<br>
AB - Yes, could do<br>
AVC - Can you get it done in this time *and* with this budget<br>
AB - If you can get someone to work for free<br>
AVC - So you can’t do this by yourself?<br>
AB - Yes, I can<br>
AVC - But not by the due date…<br>
AB - I could…<br>
AVC - But not with the other stuff you’re doing?<br>
AB - Yes<br>
AVC - Meaning no, you can’t get it done and do your other work too….<br>
AB - Not without help<br>
AVC - Which costs money<br>
AB - Normally<br>
AVC - So this current plan of you doing this by yourself by this date and with this budget won’t work<br>
AB - Not without divine intervention<br>
AVC - So when you said “absolutely”, you meant “absolutely not”?<br>
AB - Absolutely<br>
</i>
]]>

</content>
</entry>

</feed>