my former employer, pace systems group just got acquired for $21m. alas, i never got any stock, so no making out like a bandit for me.
however, what i found interesting was:
Why ePACE? Olin indicates that a key attraction was the fact that the solution is based on an open source platform running on the Linux operating system.
as the lead architect of the system, reading this makes me proud. its using some very battle-tested technologies. apache avalon as the component backbone (i bet its still running in the phoenix container!), cocoon for the webapp, and all served up with jetty. we moved to an appliance model early on, shipping a debian-based machine that was turn-key
congratulations to the whole pace team, you guys did great!
edit: another good article (especially the comments) on the deal .. highlights what some of the customers liked about pace, and the industry in general.
August 4th 2008 · Tags: code, past | No Comments »
this morning i upgraded from subversion 1.5.0 to 1.5.1 via macports.
this afternoon, i tried to do a release of some software at work.. and the maven release plugin was failing! its a very odd error:
[INFO] Tagging release with the label release-0.4...
[INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-1130425261.commit . https://example.com/workstuff/release-0.4
[INFO] Working directory: /Users/osi/Documents/workstuff/trunk
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/workstuff/tags/release-0.4/pom.xml' already exists
very weird. i tried executing that same command at the prompt, and got the same error. i did a svn up, and then it worked.. hrm. thankfully, macports makes it very easy to drop back to 1.5.0, and after i did that, maven was able to release no problem.
UPDATE: using 2.0-beta-9 of the maven-release-plugin has a workaround for this issue.
July 30th 2008 · Tags: development, maven | 6 Comments »
so, you’ve found java.lang.instrument.Instrumentation. neat, huh?
now, rather than having to start your agent via the command line, wouldn’t it be neat to do what they suggest in the package javadocs and load an agent dynamically at runtime?
i had a hell of a time finding details on exactly how to do this. install an agent in another vm? sure. current vm? nah.
in randomly following links last night, i came across a blog post from dain, and it mentioned a getPid() routine that OpenJPA uses. this tickled my memory, and i went looking for the class that uses it. i found the InstrumentationFactory from the OpenJPA code. jackpot!
what they do, is use the Attach API that Sun added in Java 6 to dynamically load an agent. They had to do a trick in order to figure out the current PID, but with that, no problem!
i did need to make some tweaks to their code to have it load in my environment. if you’re working in an environment with dynamic class loaders, when the class is loaded as an agent, it will be a new instance and thus not visible to the factory as-is. to get around this, split the factory into two pieces. the agent, and the factory. the factory does not use the agent at all, it always accesses it reflectively. then, after the agent has been loaded, use Class.forName("your.agent.class.name", true, ClassLoader.getSystemClassLoader() ) to get the instance. reflectively load the stored instrumentation and bingo!
June 27th 2008 · Tags: instrumentation, java | 4 Comments »