Wednesday, August 24, 2005

IceWM whips Flux

Pros (so far):

Smart window placement
faster startup/smaller footprint
ease of customization, configuration files much simpler
good preference tools
invokable menu by key-binding
gaim doesn't crash (compared to flux 0.9.12)
mouse focus more consistent--this drove me nuts in Flux

Tomcat whips JBoss

In order to deploy CDOL into Tomcat 5.x:

1. download Tomcat 5.x, http://www.reverse.net/pub/apache/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.tar.gz or http://www.reverse.net/pub/apache/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.zip

2. [un] tar/zip the Tomcat download.

3. modify this snippet to correctly point to the right properties file:


type="javax.resource.cci.ConnectionFactory"/>



factory
org.lds.jca.properties.LdapFacadeManagedConnectionFactory


PropertiesFileName
/ext/forge/unity/imsteam/build/rollinsrc.properties




4. modify "//server.xml" file by adding the above snippet, insert it after line 378 (following and before ).

5. modify "//web.xml" by replacing the "" element with:
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
keystoreFile="${user.home}/.keystore" keystorPass="yourpassword"
clientAuth="false" sslProtocol="SSL" />


6. copy "~/.maven/repository/commons-logging/jar/commons-logging-1.0.4.jar" into "//common/lib"

7. copy "~/.maven/repository/log4j/jars/1og4j-1.2.8.jar" into "//common/lib"

8. copy "~/.maven/repository/j2ee/jars/j2ee-1.4.jar" into "//common/lib"

9. lastly, to run the build/deploy to build the war and copy into "//webapps"

10. startup tomcat, "//bin/catalina.sh run"


Using Tomcat has sped up my build/deploy time from >=160s to <=30s, hooray for Tomcat.


NOTE:
If you're on Linux and downloaded the JDK from Sun, double-check that "javac" has executable permissions.

Tuesday, August 23, 2005

Localized dates the JDBC way

An investigative coworker (Todd) found this that explains a method of translating a given Calendar object into a GMT Timestamp. Likewise, retrieving the date in a specific locale can be achieved through ResultSet.getTimestamp the Timestamp can be localized. Now that all of the code for *doing* this is already in place it'd be a mighty pain to rip it out and refactor.

Implementing the above is a great option if you need a blanket solution. Frankly, I agree with Todd that we should be storing everything in GMT anyway. At this point in the game that's not feasible and we need specific GMT/Localizable functionality on only a few specific columns. Future situations may present alternative necessities.

Friday, August 19, 2005

Maven and Emacs, the romance and beauty

Hot dog, this is great:
Maven JDEE plugin
and
more functionality here
and here.
That last one is especially great because of the ability to run goals with the Maven console. Really speeds up dev time having it open and instantly executing goals--with the ability to click on compile errors and have them immediately opened and focused in the primary Emacs frame. Loving it so far.

Monday, August 15, 2005

VPN

http://oit.uta.edu/cs/network/vpn/linux/vpn_linux.html
copy to /usr/portage/distfiles
emerge cisco-vpnclient-3des

copy .pcf to /etc/opt/cisco-vpnclient/Profiles

then:
vpnclient connect <profile> user <username>

because Windows keeps jacking my clock

Of course the real solution is to eliminate the Windows partition altogether--and if I was done with school, that'd be acceptable.

Instead, here's a Ruby time synchronization hack/work-around I'll place in my startup script.

#!/bin/ruby
require 'net/http'
require 'date'

proxy_addr=ENV['http_proxy'].split(/:/)[1].split('/')[2]
proxy_port=80
#handle the case when the proxy_addr is null
date=nil


while(date == nil)
#fetch date
begin
Net::HTTP::Proxy(proxy_addr,proxy_port).start('www.google.com') {|http|
http.read_timeout = 1
http.open_timeout = 1
p = http.request_head('/')
puts p['content-type']
puts p['date']
date = p['date']
}
rescue
puts "is net connected?"
end

#set date
if(date != nil)
puts date
datetime = DateTime.parse(date)
puts datetime
mst = (datetime.new_offset(-0.25) )
#will need to determine if this is during daylight savings or not and adjust fraction accordingly
puts mst

#parse and format for posix
dates = mst.to_s.split('-')
times = dates.to_s.split(":")
finalDate = dates[1]
finalDate += dates[2][0,2]
finalDate += times[0][9,11]
finalDate += times[1]
finalDate += dates[0]
puts finalDate
`date #{finalDate}`
end
sleep(1)
end

Friday, August 12, 2005

Localized date resolution

Changing the datatype on our Oracle columns to Timestamp was one important step. Next, LocalizedTimestamp was created (implementing Hibernate's UserType for necessary integration) extending Timestamp and adding a bunch of constructors for multi-purpose instantiation. Moved all of the date converstion stuff into a separate abstract utility class. Followed the code-generation logic in the previous post and added a separate getDateValueLocalized(TimeZone) for specifically localized date columns (also, the date is GMT-ized going in on those same columns).

Took about two days, with the bulk of the work being in the refactoring of existing code and ensuring correct behavior via unit tests.

Wednesday, August 10, 2005

more headaches with localizing dates

Per the previous post we have decided upon normalizing dates into standard UTC/GMT times (at midnight of the day they occurred). Using the code generation tools that we have it was simply a matter of adding the necessary logic in the setters and getters of those fields on the domain model objects. So, if a date field is a GMT date we add in:

this._dateValue = new java.sql.Timestamp(setDateToUtcHourFromTimeZone((java.util.Date)dateValue).getTime());


Where setDateToUtcHourFromTimeZone is going to find the TimeZone in the session, modify the date value to midnight at that TimeZone and then translate the midnight date value to real UTC/GMT time.

Likewise fo the getter:

return new java.sql.Timestamp(getTimeZoneDate((java.util.Date)_dateValue).getTime());


Where getTimeZoneDate will translate the Date (which is GMT) back into the correct TimeZone date.

So, what's the problem with this? The problem is Hibernate calls the getters and setters. It's just fine and dandy when you set the value via the object. But, once that DMO gets into Hibernate's clutches it calls the getter on it which effectively negates the intended GMT normalization! And again, when Hibernate creates the object and calls the setter the GMT date retrieved from the database is then retranslated into a different value rather than the desired the translated local TimeZone date ).

What's the solution? If you're using Oracle , evaluate the Timestamp with timezone datatype. Same thing with PostgreSql. If not, what now? Use a varchar and muck with the values through the data access code? That's nasty and then you lose all major benefits of the RDBS datatype operations. Varchar operations could be more CPU intensive compared to numerical datatypes, especially as record sizes ramp. If I find out anything more I'll update.

RESOLUTION

So it's not going to be too difficult to fix this issue. The changes will be as follows:
1) generated DMO code will not hose with the getter, it will return the value as-is.

2) generated DMO code will have additional method for obtaining the local date value given a TimeZone.

3) generated DMO code will still use the above function but its signature will change to use a LocalizedTimestamp object.

4) LocalizedTimestamp object to be created. Has a Timestamp value and a TimeZone value. Default TimeZone is GMT.

Implementation details

The setter calls setDateToUtcHourFromTimeZone and passes in the LocalizedTimestamp. Internal logic evaluates that this is either a GMT Timestamp or not. If it is, translate, if not, keep original value. This way the code is smart enough to not hose the value if it is already GMT.

As for the getter, we'll toss on a new method (getLocalDateValue) that will require a TimeZone and will translate the value for the caller.

Thus, we satisfy the setter/getter issue for Hibernate operations and still provide necessary functionality for the additional callers.

Wednesday, August 03, 2005

test #4, w/4.6 dev

ran again with -Xmx1200m with same results.
----
java -Xmx1024m -classpath /home/russ/.maven/repository/junit/jars/junit-3.8.1.jar:/home/russ/.maven/repository/ims/jars/imsobjects-1.2.0-SNAPSHOT.jar:/home/russ/.maven/repository/db4o/jar
s/db4o-4.6-java1.2.jar:./target/test-classes junit.textui.TestRunner org.lds.ims.objects.TestDb4o

.Loading database with: 1000000 ids(2x), names, people

573565ms elapsed for task
Looking up Person by id 113322
1ms elapsed for task
Looking up Name from Person
[db4o 4.6.004 2005-08-03 22:47:42]
Uncaught Exception. Engine closed.
[db4o 4.6.004 2005-08-03 22:47:43]
Please mail the following to info@db4o.com:

java.lang.OutOfMemoryError

Closing database
0ms elapsed for task