Thursday, December 27, 2007

ServiceLoader

In Java 6 sun introduces the ServiceLocator class. It's an interesting implementation of the Service Locator Pattern.

Before, the way to perform service look-ups usually involved creating some kind of object registry and/or used JNDI. I even created an example service locator using JNDI quite a few years ago. Though completely obsolete now, I've long since switched to the Spring Framework's JndiObjectFactoryBean.

This new facility allows you to swap implementations by swapping out jars on the classpath. Though I expect the actual usage to be pretty limited as dependency injection frameworks are pretty well dominating the development scene. The primary use will most likely be for libraries that implement common APIs.

I can see an interesting use though. There is a growing trend (that I've been pushing myself for about 5 years now) of writing configuration in a programming language, like java. The idea being that the configuration can be validated by a compiler, and maintained with advanced development tools. Imagine completely separating the configuration from the application. If a framework like Spring is used, a factory class can be created that performs the service look-up for the rest of the application's configuration. Then application configuration can be handled by dropping in a small jar, instead of rebuilding the entire application.

The downside? Creating a text file under the META-INF directory. Sound bad? yes. But, I actually believe this will be the greatest hindrance to broad adoption. Laugh if you will. A text file, whose name is the interface name containing the name of the implementation class (nothing else) may be the 2nd biggest blocker (the first being D.I.). Unfortunately, about 90%+ of the Java devs I know don't know how to add items to the manifest of a jar, and/or don't even know what its for. Most people seem to think there's a lot of voodoo in the meta data directory and are scared to touch it.

Though this is a cool new feature for Java, it would have been more useful about 7 years ago. D.I. has really made the Service Locator pattern mostly obsolete. My best answer why, I've noticed that the popularity of D.I. is directly proportional to the popularity of unit testing. Simply put, D.I. makes for classes that are easier to test. Testing in a look-up environment usually involves creating a stub (mock if you will) factory that can return test implementations of interfaces. A lot of work when the tests will be simple.
.
.

Labels: , , ,

permalink
Links to this post
0 comments

Sunday, December 23, 2007

OSGi Groups and News

Here are the few groups on OSGi I've found for keeping up
OSGi - Yahoo Group
OSGi - Google Groups
OSGi Samples - Google Groups
Eclipse Equinox News Group

Apache Felix Mailing Lists
The Eclipse Equinox Mailing List

OSGi Blog

Any I've missed, please add a comment

Now it's time for me to make an RSS agregator to collect all of this data
.
.

Labels: , , ,

permalink
Links to this post
1 comments

Getting Equinox Ready for Prime Time, First Steps

I'm looking at getting Equinox ready for a server, as mentioned in a previous post.

The way I see it, there are some first steps that need to be addressed.
  • Create startup/shutdown scripts (live in /etc/init.d for safe (clean) starting and stopping

  • Create a means to connect an Equinox console to a running instance, to deploy (or un-deploy) bundles, without restarting.

  • Ensure the above can be done securely
Maybe these have been addressed but, all my Googling has shown to be fruitless.

Thoughts?
.
.
Maybe these have been addressed but, I feel like I've already spent more time searching for a solution than if I had just written it myself. Sometimes, I wonder if this is why we find so many re-implementations of problems in the open source world.

Update: I just had a random thought, maybe using JMX instead of a remote console would be a better means to (un)deploy bundles in a running Equinox...
.
.

Labels: ,

permalink
Links to this post
0 comments

Friday, December 21, 2007

Cisco VPN and Linux WiFi

I've been getting rather sporadic success using the Cisco VPN on my Linux laptop.
Through a little experimenting, it appears to have something to do with the wireless daemons running.

So, I've made a little VPN start-up script to reset everything.
So far, it appears to work 100%, woohoo!

#!bin/bash

sudo /etc/init.d/waproamd stop
sudo /etc/init.d/wifi-radar stop
sudo /etc/init.d/wpa-ifupdown stop
sudo /etc/init.d/xsupplicant stop

sudo /sbin/dhclient

sudo vpnclient connect MyKey.pcf user myUserName pwd myPassword

permalink
Links to this post
0 comments

Tuesday, December 18, 2007

OSGi and the Small Guy

After seeing a few presentations on OSGi at the Spring Experience conference. I've become inspired about how this can be useful for the small guy, not just for big enterprises.

Many of us use hosted web services to run small and personal sites. Generally, with a small site, there are a few major pieces of software that they all have in common (the parenthesis show what I currently use).
  • Web Server (Tomcat)
  • Mail Server (James)
  • Database (PostgreSQL)

If you are on a shared host, memory tends to be at a premium. For example, I use JVDS, for willCode4Beer, and only have 128MB of ram. I'm a java dev so I like running Tomcat. Running all of the services can really limit how much I can do.

Looking at OSGi, I'm considering moving to a model where everything can run off of the same virtual machine. This will also allow me to strip down the Linux install to a bare minimum.
My idea it a model like the following:



My latest searching indicates that Apache Derby can run as an OSGi module. I'm not sure if Tomcat can but, I know Jetty can (I could also write a bundle using the embedded version of Tomcat). I know that there is not an OSGi bundle for Apache James, but, I can always write it.

Anyway, there's my idea. I'm going to dedicate a little time to get it up and running. The best part is, where the various projects share libraries, I should be saving quite a bit of RAM, let alone the amount saved by running in the same VM.

Being able to deploy mailets to the James server without restarting will be nice too. Just imagine, deploying web apps and mail apps dynamically.

Scalability? Basically, its a feature of OSGi but, imagine running on top of Terracotta (the mind explodes).

Guess I have a little work ahead.

Update: I just realized, of course there is an OSGi bundle for Tomcat, it's used in Eclipse. Doh! :-)

Resources:
Tomcat Bundles
Derby Bundles
Jetty Bundles
.
.
.

Labels: , , ,

permalink
Links to this post
6 comments

Thursday, December 13, 2007

Annotations and Spring

At the Spring Experience, in several different sessions, there is quite a bit of coverage of different uses of annotations. I may have to update my list.

One of the really interesting uses (maybe I'm just ignorant here) is to identify classes and methods to apply point cuts with AOP. This seems like the perfect use of meta-data. This one isn't necessarily a Spring thing, just cool.

The use of annotations in the MVC project have some good and bad. One good thing is the use of an annotation to identify a controller, rather than having the controller extend the AbstractController. This means the class doesn't need to depend upon Spring classes. This should help preserve backward dependability (to your app) as the framework evolves.

Another cool thing is the ability to decide which method gets called by the value of a request parameter, via annotation. This changes to a more declarative model of programming that should make code easier to develop and much easier to test (less logic, less to test).
@RequestMapping(params = "action=delete")
public void removeSite(@RequestParam("site") String site,
&nbp;&nbp;&nbp;ActionResponse response) {
.


Then there is a scary part, using annotations to map URL patterns to controllers. This means the URL patterns will get scattered around the code base (hopefully in only one or two packages). The XML configuration isn't perfect but, personally, I'd like to see URL mappings in one place.
@RequestMapping("/myAction.do")
public void handleAction....


An interesting thing of the how annotations are used in Spring is in many places they help remove dependence on Spring classes and interfaces. "Use Spring but, don't depend on it".

@PostContruct and @PreDestroy (function are obvious from the name) are pretty cool.
@Resource both powerful AND dangerous (this one is for annotation driven dependency injection). Using this could make unit test more challenging.
@Autowired is a good way to reduce XML if auot wired beans don't scare you.


A little validation for my attitude with annotations. During Rod Johnson's presentation on The State of the Art Dependency Injection, he said that he like annotations but, not annotations that take strings (even the stuff in Spring). At least if I'm crazy, I'm not alone
:-)

Update: reference to this post on DZone
.
.
.

Labels: , , , , ,

permalink
Links to this post
8 comments

Wednesday, December 12, 2007

Spring Experience 2007 Meet and Greet

Update for the first day at the Spring Experience. Made it through registration. It's amazing the number of people waiting in line for it to open. Something you can say about the Spring crowd, they are pretty enthusiastic, as well as pragmatic.

I've met quite a few people here and even though they have great enthusiasm for working with Spring, they are pretty reserved and analytical about adopting technologies. They offer the cool-aid here but, nobody drinks ;-)

It's really cool being able to meet so many smart people in one place. I managed to have a fairly long conversation with Hal Hildebrand from Oracle. He's a very smart guy, and we exchanged a lot of ideas about Spring, development, practices, and techniques for attacking both large and legacy applications. This guy knows a lot of stuff about OSGi (that's a real understatement).

After registration, I attended a (exclusive the email said) Birds of a Feather (BoF) session with Rod Johnson, the guy behind it all. It really looked like an opportunity for him to get a feel for what folks are working on and what challenges they are facing. Of course, I piped in about unifying configuration. He answered lots of questions, and is a pretty down do earth guy. It's pretty cool getting to talk to others about their issues and solutions too.

After dinner, there were the Keynote speeches, that are the standard fair for any conference. In an interesting twist, most of the Keynote didn't really mention Spring but, instead talked about a lot of the issues we (developers) face and how the market and solutions are moving. When showing charts about how technologies are progressing (growing, dying, etc), most of the metrics were based on job postings. I swear there's some espionage going on, several associates and I have been saying for a long time that the job market provides the only truly valid metric.

During dinner, one of the guys at the table was showing off his iPhone. We got to talking about the built in browser, and he navigated over to my site. A nice little ego boost came when I discovered that he as well as some other people were visitors. WooHoo, somebody other than me uses it.

He showed the camera in the phone also. Below is a pic of Brian and I from the iPhone.



After the speeches, there was a meet and greet kind of party. All of the speakers were there just hanging out. One, name removed to protect the guilty, almost let slip some announcement for tomorrow. Should have caught him later after another beer or too. Ah well, guess I'll wait; no exclusive report tonight.

Update: How could I forget to post a picture of the Rod Johnson bobble head.

Labels:

permalink
Links to this post
1 comments

Flying the Red Eye

Brain is tired.

First plane left 30 minutes after midnight. Fell asleep while the plane was still at the gate. Woke up at 20K feet and a stewardess offering bitter coffee. Drank half the cup before falling back asleep. Woke up again, preparing to land, half cup of cold bitter coffee still in hand.

Seems every time I fly, the seats are smaller, and closer together. At least the airlines offset this by calling it "improved" customer service.

I am beginning to think the role of the flight attendant is simply to keep the passengers just a little occupied. Little cups of soda, over-salted peanuts. Little baggies and napkins in a tight space. The passengers get to be mildly occupied with this rather than confront the boredom of sitting in cramped seats with little ability to move for several hours.

Once upon a time, I think the occupation was meant to distract people from fear. Now, air travel is so common and mundane, it's probably meant to keep us all from going nuts.

Some folks like to occupy their time visiting the bathroom on the plane. Judging from the number going just after take off, I'd say many were saving it. These folks unfortunately annoy the other passengers. Especially, the poor schmucks stuck with seats in the rear. If you've had that seat, you know what I mean.

There are the gadgeteers, these are probably the least annoying (maybe I say that because I fit in the class). They tend to stay to themselves, and don't engage you in conversation. Whether it's a laptop, video games, or just music, they always use headphones.

Near the gadgeteer, is the middle management explorer. These poor souls travel often. They apparently spend most of their flights reading and responding to the emails that have collected in Outlook. When you wonder why you inbox is so full from that guy or gal who's out of town. Well, they are bored, tired, sitting on a plane, and trying to stay busy rather than contemplate the meaninglessness of it all.

And here I am, composing a blog message, sitting at 25K feet, on a connecting flight....

I'm just too tired to contemplate the meaninglessness of it all.

Is there anymore bitter coffee?
.
.
.

Labels: , ,

permalink
Links to this post
0 comments

Tuesday, December 11, 2007

Annotations, the Good the Bad and the Ugly

I'm a little late jumping on to the Java5/6 bandwagon. I'm one of those big strong typing / type safety advocates. It comes from spending a lot of time on big projects where tracking down trivial errors is a process unto itself.

Naturally, I find the new generics to be a blessing. When you are in favor of type safety, casts always make you cringe.

I must admit that I basically ignored the annotation system for a while. When I did start using it, I saw things like @Override, "hey this is good to protect code while refactoring." I saw the Spring framework's @Required (ensure classes are properly configured). These seem like good things, communicate with the compiler, communicate with the frameworks. This establishes a rule in the first case and a requirement in the second.

Then things start to go grey. The @SuppressWarnings mostly finds itself being used when using code that does not support generics (J2EE : request.getAttribute()). Ok it's a necessary evil, I admit.

Then EJB3 starts down a darker path. @TransactionAttribute(TransactionAttributeType.REQUIRED)
do we really want to define this in the class?
What about JNDI lookups @Inject(jndi-name="java:comp/env/jdbc/test") ?

Finally, it gets down right ugly
@Resource(name="myDB", type="javax.sql.DataSource.class")
@Table(name="CUST", schema="RECORDS")

Finally, we start to see annotations with SQL in them
@SQL(statement="SELECT * FROM USERS WHERE {sql: where}")

Finally, there's the ultimate abuse (from Google Guice):
@ImplementedBy(ServiceImpl.class)
public interface Service {

This one is so bad it doesn't need explaining.

Like many things, I think annotations can be very useful when used correctly. What bothers me most is when Sun is the one promoting obviously bad practices. Really, what's the difference in using annotations with SQL in them or just writing plain old JDBC? not much. If the configuration is in the code being configured, then what's the point of an annotation?

To be fair, I could agree with doing this if it was contained to configuration classes. By this, I mean a handful of classes that sit in a package all to themselves and serve to replace XML configuration. Configuration classes benefit by providing compile time type safety, and can exploit tools for auto-completion. But, sprinkling these kinds of annotations around the code base is going to make for maintenance nightmares.

The way I see it:
annotations to make code easier to configure : Good
annotations to enforce local policies : Good
annotations to define requirements (contract) : Good
annotations to configure : Bad

Update: I've just received an email about Loom and how it uses annotations for validation on beans (value objects to the rest of us). The idea being that the logic can exist in one place instead of at every tier (web, middle, data access). It can read the annotations to generate javascript for page level validation, and use the same annotations to validate the beans in the other tiers.

I haven't looked at Loom myself so, I'll reserve judgement but, on the surface this appears to be an interesting (read innovative) way to use annotations.

Update: while talking to a colleague, he mentions that much of the 'bad' use of annotations looks like C macros in sheep's clothing.

Update: reference to this post on DZone
.
.

Labels: , ,

permalink
Links to this post
9 comments

Monday, December 10, 2007

Bluetooth Headphones on Kubuntu (Dell Inspiron 1520)

A little update on the Laptop.

I picked up a nice set of Bluetooth headphones (Motorola S805). I needed some phones and I'm sick of cables everywhere (the Inspiron has built-in Bluetooth).

I added a post on my main site about how I configured Kubuntu to work with my Bluetooth headphones. Though a bit tricky, it wasn't too hard to get them working.

Now, I need to get a Bluetooth adapter for my Sansa for the airplane :-)

Labels: , , , , ,

permalink
Links to this post
1 comments

Spring Experience 2007

It's that time of year again. I'm getting ready to attend the Spring Experience conference.

Last year's was completely awesome. I learned sooo much and was completely worn out. There's nothing as good as crashing completely exhausted from learning so much.

Trying to decide which sessions to attend is always the hardest part. There are so many cases where I want to attend several simultaneously.

Here's my itinerary so far:

Thursday, 13 December


Five Aspects You Don't Know About
What's New in Spring 2.5?
Task-Focused Programming with Eclipse Mylyn
The State of the Art in Dependency Injection
Rapid Fire: The Coherence Data Grid

Friday, 14 December


AspectJ for Spring Developers
Focusing Enterprise Java Development: Mylyn and Spring IDE
Scale Out Your Spring Applications in 3 Simple Steps
Spring Web Flow Hidden Gems

Saturday, 15 December


Architecture Enforcement with AspectJ and Other Tools
Rich Web Forms
Spring OSGi Update
From "Hello World" to Real World : Building Web Apps with Spring OSGi

Lots of good stuff. I'm really looking forward to the OSGi presentations. I've got a feeling that OSGi may be the wave of the future for enterprise development. I expect the Mylyn to be good to. I want to get Mylyn running at work but, first I've got to build a connector to the very old version of Bugzilla we use.

I recently upgraded a project from Spring 2.0 to 2.5 so, I'm looking forward to learning about what other things I can do with it.

I'll keep updating the blog as the events progress.

Labels: , , ,

permalink
Links to this post
0 comments

Thursday, December 06, 2007

Factory Methods over Constructors

There is a lot of talk about how singles are harmful. Many of them make very good points. However, I think one thing that is generally missing from the discussion is a small pattern that is almost universally used when implementing singletons.

I mean of course, the factory pattern.

Very few people provide public access to singleton variables, they are usually provided via an instance() method. The class is its own factory object.

Why is this good?

It means you don't have to use singletons, though they could be an option. Say a class needs to operate on a non-thread safe class (an xml transformer for example), or it uses a library of uncertain thread safety. Instead of having a static reference to the instance that is returned by the factory method, it could use a ThreadLocal to ensure that each thread has its own instance. This gives the ability top address issues with threads while gaining the benefits of a singleton.

Another use of the factory pattern can be object pooling. If the object is pretty heavy weight, or requires a lot of set-up, you obviously don't want to have too many instances floating around or don't want to create them too frequently. You could write your own pooling implementation or use the Jakarta Commons Pool.

If a singleton is the right thing to do, then it should obviously be used. Consumers of the class should not have to worry about whether or not it is a singleton. Of course, this also means you shouldn't be storing state information in the class (but, you knew that).

What does this mean for testing? A private constructor is still going to prevent over-riding the class to create "truly" new instances. This means another option will have to be taken.
Perhaps the easiest is to over-load the factory method with one that always returns a new object. If the scope of this method is limited to package level, then little more than the test case should have access. The problem here is, an overly cautious developer may discover the method and use it instead of the factory class.

I would propose testing the class the same as it will be used. If there is a concern about internal state, write tests to cover it. Besides, maintaining internal state in class provided by factory methods is generally a bad practice. Try writing tests to ensure this isn't happening.

Another option could be to refactor so that a separate factory object is used, and it could be over-ridden to provide a class for testing...

Though there are problems with singletons, don't throw out the baby with the bath water. The nature of a good singleton makes it easy to do things beside a single instance in a very transparent way.

Labels: , , , , ,

permalink
Links to this post
1 comments

Wednesday, December 05, 2007

XML to JSON

Recently, I came upon the need to provide AJAX support for a site where the XML data comes from a remote site.

Security settings on the browsers prevent making a request to a non-originating server so, the solution is to create a proxy servlet.

Also, parsing XML generally sucks, parsing it with javascript is worse. To deal with this, the ideal solution is to return JSON instead of XML.

So, with a combination of the Jakarta Commons HttpClient (its just more robust than the java.net.HttpURLConnection), a cool schema to convert xml to json, the quintessential xml/xslt transformer, and a little glue, a solution is born.

Some things to note.
Use the version of the schema in the issues part of the Google Code page. It contains some useful bug fixes.
The transformer should work on streams instead of files (of course).
Be smart about thread handling with the HttpClient (cache results to minimize use of the HttpClient if you expect any kind of serious traffic).
Be sure the XML file is encoded the way you expect (UTF-8, ISO-8859-1, or whatever). If you get some crappy, I mean mis-encoded data, you can fix it when creating the InputSource:
Source source = new StreamSource(
   new InputStreamReader(xmlIn,"ISO-8859-1"));


For unit/integration testing, I highly recommend using the Rhino JavaScript interpreter. You can feed the JSON and your script to it to ensure things work the way you expect. A little jUnit to run things and life is good.

Labels: , , , ,

permalink
Links to this post
1 comments