David Leader wrote:
>However, I would rather hide the database from the user (especially as it
>is a folder/ directory with zillions of files and subdirectories), within
>the app package. The way that the jdbc works (correct me if I'm wrong), I
>was unable to communicate with the db if I included it in the jar file
>containing the class files, but I could access it in the Resources
>directory in the .app if I set WorkingDirectory as $APP_PACKAGE/
>Contents/Resources/Java in the Java section of the Info.plist.
Out of your entire description, this is the only part that seems truly
strange to me. Basically, what you've described comes down to "the db will
only work from the current directory", and to me, that seems wrong, broken,
or crappy. In short, you're using a side-effect to configure where the db
writes files, rather than configuring its write-dir directly.
The thing is, how to configure a db to write to a specific dir is usually
specific to the db itself.
That said, HSQLDB is something I've done a little work with. It's also an
embedded all-Java db. The way to configure it to work in a certain
directory is to put the pathname in a Properties object, under a certain
key whose name I can't recall but is in a source file I have somewhere,
then create the JDBC Connection passing in that Properties object. It's
simple, and documented for HSQLDB, but for other db's, who knows.
I suspect Derby is similar, in principle if not in exact practice. That
is, I suspect there is some configurable value you use to tell Derby where
to put its files. This could be a Properties object, or another
collection, which you make and then pass in to get a Connection. It might
also be a system property with a specific name. You'd have to refer to the
Derby manual or other reference to find out.
Once you know what to configure Derby with, I suggest the following.
First, DO NOT change the WorkingDirectory property in Info.plist. Instead,
define a name/value pair in the Properties dictionary, with a value of:
$APP_PACKAGE/Contents/Resources/Java/derby/
or whatever dir inside the app-bundle you want to use to store the Derby files.
If the Derby config is directly via a system property, then use the name of
that property directly. If Derby config is via a collection you make and
pass in, then pick a name like "my.derby.dir" and use that as the prop-name
in the Properties dictionary of Info.plist. Then write code to get the
System prop "my.derby.dir" and use it.
The Java launcher will expand $APP_PACKAGE in Properties values, so the
value you get will be correct. This expansion ONLY occurs if $APP_PACKAGE
is at the start of the value, not if it's embedded.
Finally, there is a permissions issue with embedding writable files in an
app-bundle. Whoever installs or copies the app will end up owning the app,
and typical default permissions will deny write to anyone except the owner.
You have to make the dir holding the files world-writable, which has its
own security implications.
If world-writable inside an app-bundle is a problem, I suggest using the
/Library/Application Support/ folder to create a sub-dir in which you place
all of your app's writable db files. An alternative I've also used is to
create a dir in /Users/Shared/, because it's a world-writable sticky dir,
unlike /Library/App Support/, which is admin-writable non-sticky. (Read
'man sticky' for the significance of stickiness.)
Again, I'd assign the Derby-files pathname in a Properties name/value pair
in Info.plist, but in this case it'd be mainly for knowledgable users to
reconfigure your app. A hard-wired location won't always match up with a
site's security policies.
>I'm in a catch-22 situation, but surely I should be able to set the save
>dialogue so that it defaults somewhere outside the application package.
I've had mixed success with that. That's one reason why I suggested
looking up exactly how to tell Derby where to write files, rather than
relying on the side-effect of changing WorkingDirectory.
>Other details. Most of the application GUI is written in Swing (java 1.4),
>but I use the AWT FileDialog,SAVE for saving the png, rather than whatever
>the Swing equivalent is, because I detest of Swing open and save dialogues
>as they are completely un-Mac-like. However I am aware of the limitations
>of the AWT, so if there were a way out here I might reconsider.
The file-chooser from the Quaqua PLAF is much more Mac-like. Google for it.
It can be used by itself, without using the rest of the PLAF.
Even if you go with Quaqua, I still think you should configure Derby to
write to a specific dir. The WorkingDirectory side-effect seems a bit
fragile to me. YMMV.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
