BibleGateway.com Verse Of The Day

Sunday, May 18, 2008

Jboss SQL Deployer

I whipped up a fairly simple SQL deployer for Jboss this past week. It is currently fairly limited, but also very straight forward and should be easy to maintain.

It consists of a class implementing java.lang.Runnable (a Thread) that wakes up every 20 seconds or so and scans a directory for any new SQL files. Of course there is also a class implementing java.io.FileFilter to look for just SQL scripts. To turn this into a JMX service, I wrote a simple BeanShell wrapper to drop into the deploy directory.

Once a SQL file is found, the code assumes the first line will contain the DataSource JNDI name, so it knows what database to connect to. Then it currently assumes the rest of the file is one query. The query results are formatted and dumped to STDOUT.

To make this truly useful, I will have to make it accept updates as well as queries, and parse the file looking for multiple SQL statements instead of assuming it is just one. Other than those limitations, it works great with the few tests I have done so far. I have been testing under Jboss 4.0.3, but this should work with any version of Jboss with the BSHDeployer.

SqlFileScanner.java


SqlFileFilter.java



sqldeployer.bsh



Why would you use this? That's always a good question to ask, and this time I have an answer besides "because you can".
  • Running ad hoc queries right from your app server, using the same Jboss DataSource bindings your applications are using, and from the same server your apps are running, can be very helpful in troubleshooting issues.
  • Let's say you use Realms instead of username/password in the DataSource XML descriptor, for security reasons. Now you can troubleshoot database issues as that user even without knowing the DB username and password.
  • Set up simple reporting jobs without needing an Oracle client installed on the machine -- run them right from Jboss.
Conslusion
I think I may create a new open source project to house this as well as all the other Java "odds and ends" I have written over the years, like some of the code generators, MQ tools, servlet filters, JSP tags, etc. The hardest part will probably be coming up with a meaningful project name -- who wants to download and install "RobbsRandomJavaCrap.jar"?

Tuesday, May 13, 2008

The Wait Is Over

We applied for our pistol permits a few weeks ago, and finally got them this past Saturday. It took 2 days shy of 3 weeks from the time we turned the applications in to the time they arrived in the mail. That's the great thing about Wayne County. Just a few miles west, in Monroe County, it takes anywhere from 6 months to a year to get your permit. Our sister-in-law applied over 2 months ago. She's still waiting.

So the first two days of having our Springfield XD-9, we fired about 170 rounds of ammo through it. That thing is really fun to shoot, but it could start to get expensive when you tear through a magazine in about 30-40 seconds.

I'm loving the XD. I like the extra safety features like the grip safety and split trigger, the cocked indicator and the chambered round indicator. And on the range, the gun shoots very nicely-- comfortable to grip, low recoil, fast follow-up shots, no jamming or misfires. The XD is also extremely easy to take down and put back together without any tools. And while a lot of handguns have a reversible magazine release, the XD simply has a magazine release on both sides -- no need to change anything. It also has a built-in accessory rail for tactical flashlights or laser sights if you so choose.

The XD came with a plastic carrying case, holster, 2 magazines, a speed loader, magazine holster that holds 2 magazines, cleaning brush, and a gun lock. Gander Mountain threw in another gun lock and a "gun sock".

My decision came down between the Springfield XD or the Beretta PX4 Storm, and I can honestly say I don't regret my decision at all. The Beretta is a nice gun, but if I were to buy another handgun, I would get another XD in a heartbeat.

Monday, May 12, 2008

Homesteader's Delight

We ordered our chickens over the weekend from Murray McMurray, after having some poor luck getting birds locally this year. Instead of just getting chickens, we opted for the Homesteader's Delight, which is described as such:
If you are a small land holder and would like a small number of birds but a great variety, this is the assortment you've been waiting for. We will send you 10 Brown Egg Laying Chickens (female), 2 Ducklings (straight run), 2 Goslings (straight run), and 2 Turkeys (straight run). Our choice of variety of all the above.
The variety should be interesting. They should be arriving the week of May 19th. Time to get that coop cleaned out!

Thursday, May 01, 2008

Some Old-School JAM and JPL Tips

The JAMster Speaks...

I was cleaning out the barn and found a CD of some old code and documents I had written at an old job, kind of a "portfolio" CD if you will. We used JAM to build Motif screens.

JAM let you visually build your screens, and had it's own procedural programming language, JPL (JAM Programming Language). JAM came with the necessary C code to handle launching of the screens and handling events. You could write your own custom C code to be called from the screens, or write your code in the JPL file for the screen, or a combination of both. One nice thing is you could write SQL code right inline with the rest of your JPL (just prepend the keyword "sql") and everything was taken care of, even down to binding the result set to variables.

It's not exactly cutting edge technology now, but I know it is still in use by at least a few companies. This is not a tutorial for non-JAMsters, but rather a collection of troubleshooting tips I had taken note of. Maybe this could be of use to someone just inheriting legacy apps, or who knows when I might run into JAM again. Yuck!

For reference, these tips are mostly for JAM 5 and 7, but they may be applicable for other versions as well.
























SELECT 1 FROM table...This is often
done to see if a record meeting your criteria (where clause) exists in
the table.
Doing this from a JAM screen (at least in Jam 5) will produce a
@dmrowcount of
0 (zero), even if there are records in the table meeting the criteria.
There
are two alternatives within JAM to get the same information:

1. SELECT
COUNT(*)
temp_var FROM table...

2. SELECT
column temp_var FROM table...
SELECT column FROM
table
This one can be tricky.
If there is no JAM variable with the same name as the the selected
columns,
then JAM will create those variables and put the results of the query
in those
variables. If the variables do exist already, JAM will overwrite the
values
with the results of the query, even when the query returns nothing (it
will essentially
clear the variables).
Mixed Case VariablesMixed case variables
can be a real problem with JAM, and the error messages are not
intuitive enough
to let you know what the real problem is. Keep tihs in mind when you
can’t
figure out some quirky behaviour, and all the other logic and syntax is
proper.
Changes in screen file don’t seem to take effectCheck the local
directory you are running from. JAM will use screen, JPL, and
dictionary files fro mthe current directory before
checking in the SMPATH, regardless of what the SMPATH is set to.



Check the data
dictionary. The screen fields and variables can be stored in here, as
well as
in the screen definition file. Data dictionary tends to overwrite
local (screen) vars.
Some Useful environment VarsMost of the relevant environment variables
start with SM, e.g. SMVARS, SMPATH

  • Also worth noting is that while it might make sense that they would just make use of the underlying Motif widgets, in some cases that was not the case. Simple text boxes for instance would not work with bi-directional Hebrew whereas pure Motif screens did. We had to have JYACC / Prolifics issue a patch for us before we could release to an Israeli customer.
  • There were also issues with some characters in the Turkish (ISO-8859-9) character set. Their database layer simply could handle it for some reason. Wouldn't bring back results, wouldn't update, and yet We ended up having to write our own generic database access layer using Pro-C, and replacing all the JPL "sql" statements with "call" statements into our library.