Archive | java
Spring and Jython — what a combo!
I’ve been thinking off and on for a few month that using Spring inside of Jython would be a magical thing. You could just get a Spring ApplicationContext, call “getBean” and Jython (who doesn’t care what kind of object it is) would happily go on it’s way. No importing a ton of object — just magic. Surely it’s not that easy.
Well, this weeks I finally got an opportunity to do so. I’m working on a Spring-based application and I needed to write a script to setup some test data for my stuff. So I broke Jython out and away I went. But was it that easy? Why yes — that was all I had to do!
Of course, this isn’t Jython-centric. Any of the JVM-based dynamic languages would have this. Groovy, JRuby, Beanshell . . .
I’m sure others have already done this before, but I think it’s really cool.
Powered by ScribeFire.
Eclipse Sighting
No, note another lunar eclipse but a [totally different Eclipse.](http://www.eclipse.org/)
My mother-in-law is a [Pampered Chef consultant](http://pamperedchef.com/index.jsp?localeString=en_us) and needed some help with their consultant application called “The Pampered Partner”. As I was mucking with it, I felt something familiar about how it started up, etc. Then I saw that it left some files called “.metadata” and also a file called “derby.log”.
After I figured out what was going on with the Pampered Partner, I did a Help-> About, and clicked the Plugins button. Yep — it was officially Eclipse. I told my mother-in-law that the Pampered Partner was a version of a program that I used everyday to write Java programs.
On the other hand, this means that the Pampered Partner is truly cross-platform, yet I don’t think they “support” anything but Windows. Yet I think you could hack it to run on any platform with a JVM.
Tutoring Java
My lovely wife is always trolling Craigslist, looking to put me to work doing odd jobs. My latest odd job is a Java tutor.
I never took a formal Java class. I bought a book, trolled the web, and was given a project. The good news is that I don’t have a lot of cruft to unlearn (i.e. I never used the Vector class before, and I still can’t figure out why anyone would choose an Array over an ArrayList). On the other hand, I was never introduced to some standard classes, like NumberFormat or DecimalFormat . That said, I’ve never used them in a Java program before, either.
Early on, I asked my student if they were using Eclipse, NetBeans, etc. in the class. She had never heard of them. I gave her an assignment to download Eclipse and play with it some. When we met last next, we used Eclipse to write the homework. She was amazed how easier it was than Notepad. It tells you right away when you have a mistake! If you use a class that it doesn’t know about, it will offer suggestions and add the import statements! And it has auto completion!
The IDE suggestion was difficult for me. I’m not always a fan of IDE’s. But I think that everyone pretty much uses an IDE to write Java so also knowing a little about Eclipse will help her in the end. And the fact that Eclipse can take care of some of the annoyances in Java while she can concentrate on realizing what a for or while loop is as apposed to trying to figure out where the DecimalFormat class is located in the standard library. In the long run, knowing how a for statement works is more important than knowing all the parameters for DecimalFormat.
When we starting over over the next assigment, I was quickly reminded on how inane the programming assignments are in an introductory class. I’m not frustrated because there are easier/better way to do some things (and there are!) but in the fact that you can’t always use the most straightforward methods. In this last, the instructors give sample output, and then a laundry list of things that he wants to see in the code. Example: we needed to round some numbers to two decimal places and put commas in numbers above 999. My student had an example from class that used NumberFormat and had notes on Locale. Excellent!! We implemented it and it worked flawlessly. Then we got to the bottom of the laundry list and it said, “I don’t want to see hide nor hair of NumberFormat in your program!”
So we used DecimalFormat instead. Only that DecimalFormat.getInstance() returns a NumberFormat object! Hide nor hair, huh? How do we do that? Oh, yeah — you just just use DecimalFormat’s constructor. Then things were working fine.
Huh, that was an awful lot of work to fix already working code.
Powered by ScribeFire.
Large Datasets in a Unit Test
I spent my whole day essentially working on one unit test.
Yes, just one unit test. But let me explain.
This part of the app just does something very simple — serializes the results of a database query into XML. Of course, it’s not “simple” but we have tools to make this simple. You take some Spring and you mix in a little JiBX and they do the work. You just have to use them.
To test this, I mocked up a small dataset and used that to get the XML. I could manually check those values and it was fine. But the query won’t return a small amount of data — it will be large. At least a couple hundred items.
You could say, “Well, if it works on a small set, then it will work fine on a large one.” And, really, you are probably right. But how do you know? And how do you make sure? Since we are usually going to have a few hundred items to serialize, shouldn’t we put that into our tests? Why, yes.
My plan was thus: have my desired response in an XML file to load up and some mock data to load into the test. Getting the base was easy — I just took a snapshot of some query results and made that into the XML file. I would then deserialize the XML file into a DOM that should be the same DOM as the mock data (with JiBX, it becomes trivial to marshal and unmarshal objects into XML).
But how to get the XML object? I started by writing a Python script to read the XML and put that into a snippet of Java. To the people who don’t use scripting and/or dynamic languages this may seem strange. To me, this is natural — Python is much better at handling text and (IMHO) better at dealing with XML.
As I studied the resulting Java, I knew that I didn’t want to put that into a Java class. It was too hard to change! I didn’t want to run the script, put it into the Java class, massage it so it compiles, and then test. So I thought a while and then remembered I could to all this in Spring! I could take the XML and simply put into a Spring config, populating my data. Then, in my unit test, I could called the applicationContext
to get the object.
So I changed my Python script create an Spring config bean instead of a Java snippet. I put it into it’s own config, that I only call in my unit test. I named it mockdata.xml.
And, you know, it worked like a charm.
This shouldn’t have taken me all day, but it did. I spent too much time in the Java snippet instead of letting Spring to all the work for me. But, with the Python script, I have a re-usable solution so when the data needs to change, I can easily re-do my tests.
Testing should not only be fun, but correct as well.
Powered by ScribeFire.
Setting up a JNDI Data Source in Spring
Just put something like this in your applicationContext.xml
<bean id=”appDS” class=”org.springframework.jndi.JndiObjectFactoryBean”>
<property name=”jndiEnvironment”>
<props>
<prop key=”java.naming.factory.initial”>weblogic.jndi.WLInitialContextFactory</prop>
<prop key=”java.naming.provider.url”>t3://localhost</prop>
</props>
</property>
<property name=”jndiName” value=”data_source_jndi_name”>
</property>
</bean>
You’re properties and jndiName will probably be different. But still — no code, just configuration. It doesn’t get much better than that!
Powered by ScribeFire.
