Embedding ANT as automatic DB schema upgrader
Anyone who has developed code with other developers that uses a database can sympathize with this dialog
Joe : "Hey, just checked in some code, you need to run this SQL script to create the new tables."
Mary: "It's not working, my schema already has some of those tables from last time"
Joe: "Drop all those, maybe you better drop entire db to be safe"
Mary: "But I'm in the middle of developing something, dang I shouldn't have updated my code"
sipXconfig went to use ANT to break up these little DB schema upgrades into "patches" that are intelligent enough to know when to run and remember when they've been run before. I'm very happy with this and it actually required ZERO java coding!
Rule was you never edited a patch once it was checked in, you only patched other patches. It was still difficult in early development stages when your portion of the schema changed drastically and you left a long string of patches behind. So I came up with a patch that clears itself and applies itself everytime the application runs.
<target name="drop-firmware" if="firmware">
drop table firmware;
drop sequence firmware_seq;
delete from patch where name = 'firmware';
<target name="firmware" depends="drop-firmware">
sipx-sqlruns a SQL script and
db-patchdoes the same but also marks that the script has been applied before so that next time this ant file is run "if=firmare" will be true. Details are in the
At some point when these tables stablize, I can just change it to this
<target name="firmware" unless="firmware">
Waiting for remote video
somebody w/video call me...
Compusa had a sale on webcams, 2 Creative labs Live web cams for $70. Other one will be xmas gift so someone will call me, maybe my brother will use it.
Please, all sales final
It's how I remember what order to put my java method and field modifiers
public abstract static final ...I say it to myself half-dozen times a day, so I thought I'd share.
As a web services rookie, authentication is a challenging assignment. First question: whether to use HTTP auth at the transport level, or WS-Security at the message level. Decision: use HTTP auth. It is simpler, mature and widely supported, and meets our current needs well.
Given the four types of HTTP auth:
- HTTP Basic
- HTTP Digest
- HTTPS Client
which should we use?
We're using HTTP/SSL as the transport since sipXconfig data is the customer's private information and should be protected on the wire. So HTTP Digest auth offers no advantages over HTTP Basic. HTTPS Client auth, a.k.a. "client certificate authentication" has the extra security afforded by PKI integration, as well as extra complexity. Form-Based auth is interactive and therefore not suitable for web services.
Decision: start with HTTP Basic and support HTTPS Client later.
Implementing HTTP Basic authentication with Jetty
Jetty, the web container used by sipXconfig, is a great open source product, but the documentation is a bit scanty.
Step 1: Add security-related deployment descriptors to
<web-resource-name>SipXconfig Web Services</web-resource-name>
<!-- Use HTTP Basic authentication. -->
BEA has a good explanation of what goes in web.xml. Briefly,
security-constraintabove protects all the URLs associated with web services, declaring that only clients with the admin role have access.
login-configelement declares that HTTP Basic authentication will be used.
security-roleelement declares the admin security role.
Step 2: Now how do we change the sipXconfig Java code to make the web application support this properly? Turns out that this is completely web container-dependent, sad to say, and the Jetty documentation offers little advice. By talking to my friend Damian, grepping around the Jetty distribution, and looking at the sipXconfig 2.8 code, I figured it out.
Here JettyUserRealm is that class. If you now run sipXconfig in test mode and browse to the web services URL, http://localhost:9999/sipxconfig/services, the browser will prompt you to log in. Of course, this is just for testing, real use of the web services API is from a client application, not a user through a browser. The
JettyUserRealm test class is just a dummy implementation, real authentication via the password tokens stored in the database is the next step in our plan.