cwash into software

After fighting with WebLogic 9.2 for a while, I was able to get a seam-gen’d app running.

You’re relegated to using JPA/Hibernate because of an outstanding bug BEA and Sun seem to be both pointing fingers at each other over, but it’s not a big deal.  At least for now, all of the persistence in this app is going to be offloaded to services.

I’ll work on writing this up more formally, but here was a running list of issues I had to deal with.  If you need more information, let me know.  I apologize that this is kind of rough, but it’s better than nothing.

1. Follow steps outlined in reference guide. (http://docs.jboss.com/seam/2.0.2.SP1/reference/en-US/html_single/#weblogic)
2. Change the build.xml’s jboss.home’s to bea.home’s, and redefine them like so:

   <property name="deploy.dir" value="${bea.domain.dir}/autodeploy" />
   <property name="jboss.deploy.dir" value="${jboss.home}/server/default/deploy" />

3. Remove the library-ref from weblogic.xml (that you put in following the ref guide).
4. Remove the Namespace, Schema, and Version definitions for the web-app tag in web.xml - there’s a problem trying to add version 2.5… (https://jira.jboss.org/jira/browse/JBSEAM-2247)
5. Remove JSF/MyFaces deployments from WL domain if there are any (JSF 1.1 libraries conflicting with 1.2)
6. Add jsf-api.jar, jsf-impl.jar, commons-collections.jar, persistence-api.jar, el-api.jar, el-ri.jar (needed to pull out of seam fisheye) to deployed-jars.list.  You should be seeing Seam trying to start up at this point, IOW, you’re in “whack-a-jar” mode.

One other funky thing — and I’m not sure what error exactly was causing this (probably related to the interceptors and JSF problems causing the deployment to suspend) but WL was causing some locks to occur that I had to clear out of my domain/server/tmp/* and basically “clean” everything out.  It was quite annoying, but things seem to be better now.

If you’ve checked out my blogroll, you’ll notice I have a link to Basil Vandegriend’s “Professional Software Development” blog.  I like a lot of the articles he has written and to a large extent the subject matter I envision for this blog frequently crisscrosses with Basil’s.

While I was reading “The Reuse Trap In Software Design” I found myself thinking,”Me too! Me too!” like a giddy kid on the playground that’s found a new pal with a mutual interest in “pet snakes and/or tarantulas.”  As with many of the problems Basil writes about in his blog, I experienced the same problem, investigated it and found the same root causes, and came to many of the same conclusions as those outlined.  He describes the “reuse trap” as:

…[A] term I coined to describe the situation when one becomes stuck trying to design new functionality while simultaneously attempting to reuse existing code that needs some modifications.

He then goes on to describe why it’s a tough problem for n00bs and outlines a strategy he uses to get out of the trap–one that’s best described as a two-step process: copy-paste to reuse/refactoring to remove duplication.  I encourage you to read his article if you’re not familiar with the terms, or how this strategy can solve the problem described above.

My preferred technique for mitigating the problems involved isn’t copy-paste reuse/refactoring; it’s stubbing the calls to the code-to-be-reused (C2BR) that needs modification.  If I can fake out the behavior I need, it lets me focus on the nature of the dependency that exists between the two objects/components.  When I go to modify the C2BR, my inputs and outputs (or other consequences that occur as a result of a call to the C2BR) translate directly into a test that I can use to drive the changes I make to that code.  It also ensures that the coupling that exists between the objects is loose and legit.

The only thing to watch out for is that care must be taken to then remove the (small) duplication of the stubbed out inputs/outputs and actually wire the two pieces together when finished with the reused code.  I usually do that by throwing a TODO:WIRE marker in when I stub something.

I’ve found this is the approach I take more often, though I do take the copy-paste reuse/refactoring route from time to time.  This stub/rewire approach is a bit more advanced, but it’s how I envisioned solving the “reuse trap” when, as Basil puts it, “I became aware of it” and all that it entailed.

Do you ever come across this problem?  How do you get out of this “trap” or avoid being caught up in it in the first place?

On Tim Bray’s recommendation, I just picked up a new Apple Wireless Keyboard:

So far, it seems like a good choice.  As mentioned in Tim’s post, I notice my typing speed has dramatically increased immediately, when compared to the built in keyboard, or the stock Dell keyboards I’ve been typing on when not at my Mac recently.

I didn’t think the num pad warranted the extra space it’ll take up when I carry it around with me.  The super big command key doesn’t concern me quite as much, because I’ve gotten used to slipping my left thumb down to hit it from hovering over the spacebar, and it’s easier/more natural to do that on this keyboard compared to the one built into the MBP.

And this all goes without saying that the wireless features are a big plus.  Whenever you sit down to do something, having to plug in an extra wire is nothing short of a pain in the ass (not to mention taking up valuable port space on my precious laptop).

So far I’m pretty happy with the purchase.  If my opinion changes, I’ll let you know, but the spot judgement is that it’s exactly what I was expecting.