Truths and Lies

Introducing Swiz AOP!

2011-06-27T19:52:00.000-07:00

A few years back I wrote a series of articles introducing the principles of Aspect Oriented Programming to ColdFusion developers. In this article I will begin a similar series aimed at ActionScript Developers, in support of Swiz’s newly release AOP Framework. AOP can seem like a daunting topic, with unfamiliar terminology and concepts that can be difficult to get your brain around. Instead of simply explaining new terms, I am going to take a gentle approach, and hope that by providing context to why you may employ AOP, you will walk away with an understanding and excitement to give these powerful concepts a try. This article will simply be an introduction, with my next introducing Swiz’s new framework in practice.

If you are currently using an Inversion of Control container, you have hopefully begun to take advantage of composition in your architecture. There are many articles out there on why IoC tends to favor composition over inheritance, so I won’t get into a long-winded discussion here, but I can say that when I began to use the Spring Framework for Java back in the early 2000s I really enjoyed learning to think of my applications as groups of shared services, composed of simple bits and peaces making up powerful work units. I play guitar and bass, and I like to think of what we call ‘Services’ existing in my application in a similar way as my effects pedals exist in my rig. If you unscrew a few, you will see that they are made up of a bunch of pretty similar components: capacitors, resisters, transistors and so on, but most users never look at that stuff. They see a few knobs, an input and an output or two. These are the effect’s interfaces. Most users don’t care how they work, they only care about the bad ass metal thunder sounds they make. To me this is a great way to think of application development, and IoC containers like Swiz are amazing tools to give you the power to compose your applications without much overhead, instead concentrating on real functional design. IoC is a great tool, but it’s really the power of composition that makes it all so elegant.

Aspect Oriented Programming in some ways is like composition on powerful mind altering drugs. Going back to my guitar analogy, some players like to add midi into their rigs. They put a special little device in the signal chain that can filter some or all of their sound into a box that, although it looks pretty much like any other guitar effect, can magically transform their guitar into entirely new and some may say interesting instruments. (Authors note: I do not condone this! There is absolutely nothing bad ass about an electric guitar sounding like a flute!!) What really interests me, though, is that the altered behavior is highly controlled, at runtime, by the player. This is what AOP does for your applications. It enables developers to selectively brush complex behavior into their applications, in an extremely transparent manner. So code that is already written, tested, and composed into a complete service can all of a sudden take on entirely new behavior. Sounds pretty awesome, no? Negative side? Well, that would be what I just wrote about ‘in an extremely transparent manner’. AOP can be hard to read, and even harder to understand how it’s even functioning in the first place. A core principle is dynamically changing objects in a way that objects using them can never know. It’s powerful, confusing, and wonderful all at the same time. As I said, it’s like an acid trip for your code.

So why would you ever do this? Let’s get on to what AOP really aims to acomplish. If you look at a complex system, it is often pretty easy to break it down into many, many specialized pieces of functionality, reused in few places, and far less specialized functionality reused in many places. The first group is your core functionality, the business logic you are trying to implement. The later group is stuff you need to redo all the time, and often can look at as being pretty coupled to code all over the place. In the AOP community, this type of functionality is referred to as ‘Cross Cutting Concerns’, because it cuts across so many parts of your app. The prime example of this is logging. Open up any big AS project and you will see either a ton of trace statements or logging statements everywhere. They cut across everything, but do they have anything to do with the actual business logic one line above them? No, because logging is not business logic, it’s simply cross-cutting debug logic. Other great examples are caching and security. Instead of in-line, right when you are about to make a remote object call, making a call to some security component to make sure the user is actually allowed to do whatever they are doing, then needing to write in logic to do whatever you need to do if they actually are not allowed, it would be much nicer to simply declare that method needs to be secured somehow. If you could simply say a component needs to somehow be secured, or have it’s results cached, you could then write code, very generalized and loosely coupled code, that would allow that component to take on a new aspect of behavior. You want that object to ‘be secured’ or ‘be cached’, sometimes, and need a means to configure that behavior instead of blindly inheriting it all the time. This is the primary problem AOP aims to solve. So how does it do that?

Well, although AOP uses terms like Proxies, Joinpoints, Pointcuts, Aspects, etc, which sound terribly confusing, I like to think about it in terms of Interception and Introduction. If I want to add security to a method, I am not going to actually write any code about security into that method. Instead I can use AOP to intercept that method, then at runtime decide if I would like to introduce the security logic before actually calling the method. The beauty is, you get very readable core business logic, and as long as you understand how the AOP part is configured, very reusable cross cutting logic to implement systems like caching and security. Since this is already a pretty lengthy article, I am going to leave you thinking a bit. In the next article I will provide a functional walk-through of AOP in practice with Swiz, showcasing a simple caching solution, then move on to a full discussion of Swiz AOP’s main principles. Check back, because these articles will come fast, I promise!

Swiz 1.1 Released with Flex 4.5 Mobile Support!

2011-05-03T10:22:00.000-07:00

The Swiz team is very happy to announce today the release of Swiz 1.1!! This new release includes support for mobile development, along with some critical bug fixes and infrastructure support for future development (I'll keep what that could be a small mystery for the moment...)

We're proud to also include support for some new features included in Flash Builder 4.5, which now automatically completes Swiz metadata!

Swing on over to www.swizframework.org for details, or grab the download here. Congrats to Team Swiz for the new release!

Swiz 1.0 Released!!! And in honor, may I present FoShizzle!!!

2010-12-15T09:20:00.000-08:00

In honor of the long awaited Swiz Framework 1.0 release, available from swizframework.org, may I present for your pleasure my snoop approved, 100% chronic extension FoShizzle!!

How do I use this glorious piece of engineering you may ask?? Just drop the swc into your project, and add the following custom processor configuration to your main Swiz declaration.

<swiz:customProcessors>
    <processor:DispachizzleProcessor/>
    <processor:EventHandizzleProcessor/>
    <processor:InjectizzleProcessor/>
    <processor:PostizzleConstrizzleProcessor/>
    <processor:PreDestrizzleProcessor/>
</swiz:customProcessors>

Snoopified metadata names can be used as following:

Dispachizzle == Dispatcher
HandizzleThaEventizzle == EventHandler
Injectizzle == Inject
PostizzleConstrizzle == PostConstruct
PreDestrizzle == PreDestroy

Enjoy!!

More Swiz features, or Swiz 0.0.5 Part 2!

2009-01-29T17:52:00.000-08:00

Since my last post was getting a bit long, I said I would get a second installment out 'soon'. It took slightly longer than I hoped to get together, but it gave me a chance to put more into Swiz, that I can also blog about 'soon'!. I left you hanging a bit after mentioning Swiz's new Prototype bean, so lets get right down to business. If you've used Spring or ColdSpring before, you should be well aware that they manage both singleton and non-singleton beans. Spring 1.0 and ColdSpring provide a 'singleton' attribute for the element in your config file. The singleton attribute defaults to true, meaning there will only ever be one instance of that bean in the factory's cache, but if you change it to false, the bean definition becomes a prototype for a new instance that is created every time getBean is called. In Spring 2, the semantic was shifted a bit, and now the attribute is called 'scope', setting it to 'prototype' is the same as singleton=false. I like the shift in terminology, it's more expressive of what Spring is actually doing.

Handling prototypes, or non singletons, is pretty much a core function of an IoC container, but Swiz has a little secret, we've been getting by without it. This has a lot to do with the route I initially followed to build Swiz. Being that Flex already has a built in xml language which you use to define object instances, it seemed very natural to me to leverage MXML for Swiz's configuration. However, when you supply objects to Swiz in a BeanLoader, you are defining instances, which are cached as singletons. Even though this is extremely simple, and I could easily argue the point that 90% of all objects managed by IoC frameworks are in fact singletons, there is also plenty of reasons why you man need a unique instance every time a bean is retrieved from Swiz. For instance, what if you wanted to wire up a separate instance of a controller for each view in a tab navigator. Well, with Swiz's new Prototype bean, you can! Here's an example of the new Prototype bean in action:

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*"
                xmlns:mx="http://www.adobe.com/2006/mxml"
                xmlns:swizframework="org.swizframework.*"
                xmlns:delegates="foo.delegates.*"
                xmlns:factory="org.swizframework.factory.*">

    
    <mx:RemoteObject id="widgetService" destination="widgetService"/>

    
    <delegates:WidgetDelegate id="widgetDelegate"/>

    <factory:Prototype id="widgetController"
                className="foo.controllers.WidgetController"/>

</BeanLoader>

I've defined three objects, a delegate, a remote object, and a controller, if you've worked with Swiz in the past you can already guess how they are being wired together. However, instead of defining the controller directly in MXML, I have defined a Prototype bean, providing an id and className. This should look very familiar to users of Spring and ColdSpring, there's just one big difference to take note of. In Swiz, a prototype is by default non-singleton. You will always get a new instance anytime this widgetController is injected into a view or another bean. It's important to take note of this difference. Your normal beans are always singletons. Prototypes are by default definitions of non-sigletons. Which makes a whole lot of sense semantically. However, if you would like you, can alternately use Prototype to define singletons, by setting the attribute singleton="true". As a matter of fact, if you took this route, your BeanLoaders would look a whole lot like your Spring or ColdSpring config files! I hope you find some great uses for the new Prototype, and check back for the next installment, Swiz's new IInitializingBean interface!

Good to end on another cliffhanger, right?

A bunch of sci-fi movies I can't wait to watch with my kids

2009-01-26T18:51:00.000-08:00

Spurred on by a tweet by Ray Camden, I decided to put together a list of sci-fi / fantasy movies I can't wait to watch with my kids when they get old enough, as well as some great ones I have watched with them recently. They are 5 and 7, so no, we're not watching Alien! So, here's the 'waiting' list:

1. Blade Runner (probably my all time favorite movie)
2. 5th Element
3. 12 Monkeys
4. Legend
5. Dark City
6. 2001
7,8,9. All three LOTR's.
10. Planet of the Apes
11. Alien(s)
12. Pan's Labyrinth (maybe, it's pretty scary but it's on the appletv)

And the ones my wife has deemed 'acceptable'. Ok, some are a stretch in the genre...

1. Narnia
2. The Dark Crystal
3. The Goonies
4. Wall-e
4. Harry Potter 1,2 & 3. We decided 4 and 5 are too heavy
5. All 4 Indiana Jones
6. Of course all Star Wars, we watch the damn Clone Wars cartoon every freaking Saturday. God it SUCKS!
7. skinnyarms comment reminded me, we watched Tron recently. My kids really liked it, but were awfully confused by the 1980s concept of computers. Simon kept looking at my funny, and I know he was thinking, "you don't really make crazy stuff like that at work"!

Honorable non-sci-fi mention. We just watched The Wiz, that was very funny to watch with them!

So, what are you watching with yours?

New Swiz 0.0.5 for the New Year!

2009-01-06T18:49:00.000-08:00

Update: Just wanted to clear up a few typos. You need to call setStrict(true) before calling loadBeans([Beans]). The code snippet has been fixed. Also, I misspoke, Sönke's strict flag only supports fully qualified class names or static constants in the format SOME_EVENT (all caps with underscores). I have also made that change.

Happy New Year all! You may have noticed I've been on a bit of a blogging holiday, but after a productive for Christmas/new years, I've released a new build of Swiz over at our googlecode site! I was hoping to make a release earlier this week, but decided to take a little extra time to restructure the repository so I could include dependencies and project files to make it easier to build Swiz from source. So what's in this shiny new build? We've got two major features, and a bunch of bug fixes, which I'll list out at the end of the post. Most importantly though is run-time checking of event types for DynamicMediators, which we are supporting through two different approaches. It really only takes one or two times scratching your head over some non functioning code, only to find a misspelled event type, to see the need for run-time checking of event types. The first approach has been added by a new addition to the Swiz team Sönke Rohde. Sönke's been very active on the google groups list, as well as blogging some great articles on Swiz and talking with me quite a bit off list about Swiz enhancements. I've very happy to have him now contributing! But let's get on to this run time event checking...

If you've read the documentation for DynamicMediator, you know that Swiz looks for the Mediate annotation to essentially create a wrapper for a function to be added as an event listener for any event type. The syntax looks like the following:

[Mediate(event="user:SaveUserEvent", properties="user")]
public function saveUser(user : User) : void { ... }

Swiz will not only look for Mediate annotations in objects in your BeanLoaders, but also in any view it sees added to the stage. It then creates a DynamicMediator for the event type supplied, which passes the event properties listed into the function you have annotated. DynamicMediators can significantly reduce boilerplate code, but do have one major drawback. You can only supply string values in Flex medatada tags. It would be great to be able to write:

[Mediate(event=com.foo.SaveUserEvent.SAVE_EVENT, properties="user")]

and have the Flex compiler understand that you are referring to a property of a class, but unfortunately, it won't. However, Sönke has added a 'strict' flag, which will force Swiz to evaluate the string value of the event type as a fully qualified class name or static constant in that class, and throw an error if the class cannot be found. This will occur as soon as Swiz tried to create the DynamicMediator, effectively giving you runtime checking of your event types. In order to use this in your project, you would change your initialization of Swiz to something like the following, in an event handler for preinitialize:

private function onInitialize() : void {
Swiz.setStrict(true).loadBeans( [ Beans ] );
}

You may have noticed the method chaining style I used, which is another new change. Static configuration methods on Swiz return the Swiz instance, allowing you to chain method calls. Now if we change the mediate annotation above to:

[Mediate(event="com.foo.SaveUserEvent.SAVE_EVENT", properties="user")]
public function saveUser(user : User) : void { ... }

Swiz will first check to make sure that a class named com.foo.SaveUserEvent exists, and has a string property called SAVE_EVENT when it attempts to create the DymanicMediator. Early on, Sönke had told me that he commonly uses a standard in his development of always using fully qualified class names as his event types, so an Event class com.foo.SaveUserEvent would use a call to super("com.foo.SaveUserEvent") in it's constructor. In that case, you could use an annotation such as the following:

[Mediate(event="com.foo.SaveUserEvent", properties="user")]
public function saveUser(user : User) : void { ... }

and Swiz would just make sure the class existed. However, this would enforce that you MUST have a class for every event type, excluding DynamicEvents. By adding adding the ability to resolve a static constant, you can place your event types in any class. Let's say you had a com.foo.EventConsants class, you could use:

[Mediate(event="com.foo.EventConsants.SAVE_USER_EVENT", properties="user")]

for your mediator, and then dispatch a DynamicEvent like this:

var e : DynamicEvent = new DynamicEvent(EventConsants.SAVE_USER_EVENT);
e.user = currentUser;
Swiz.dispatchEvent( e );

I really like the flexibility of this approach. However, while Sönke was working on his strict checking approach, I was working on a similar solution to the same problem. While attending a Spring User Group meeting, I saw that they were experiencing similar issues with their move to annotation driven configuration, and was very intrigued by their 'expression language'. So I have come up with a simple implementation of my own, which I think will continue show it's use in Swiz elsewhere as time goes on.

Let's take a look at how you might use the new expression language instead of the strict approach. In my own work, I have gotten into the practice of storing event types in my controllers, for me it's a way of keeping them part of a particular domain. So in the previous example, if I have a UserController with a SAVE_USER_EVENT property, I would reference it directly in my SaveUserEvent type, calling super(UserController.SAVE_USER_EVENT) in the constructor. Since I have added my UserController to BeanLoader, with an id of "userController", I can now use an expression in my Mediator to reference the SAVE_USER_EVENT property, like so:

[Mediate(event="${userController.SAVE_USER_EVENT}", properties="user")]

When Swiz encounters the ant-style syntax I chose for expressions, it evaluates it in the format [beanId].[property]. If a bean with the supplied ID does not exist, you will immediately get a runtime ExpressionError. What's nice about this format is, you can use public static constants or instance variables for your event types,, and you can even nest them! In the earlier example using Sönke's strict flag, I mentioned using a class called EventConstants for event types. Depending on your development style, you could either provide this bean to Swiz and reference it directly in you expression, like I did with the userController, or maybe your controllers could have an instance of it, in an 'eventTypes' property. Then you can use an expression like:

[Mediate(event="${userController.eventTypes.SAVE_USER_EVENT}", properties="user")]

I think that both these styles will be a great improvement for developers using Swiz, providing a flexible model to suit your development standards. Unless I have strong community outcry to adopt one format over the other, I see no reason not to support both. Well, this post has already gotten a bit long in the tooth, so maybe I'll leave this as part one, and let you know that part two will cover, Swiz's new Prototype bean! So go download the new Swiz 0.0.5 library and happy coding!

Changes / Fixes for Swiz 0.0.5:

- DynamicChannelSet now contains an 'endPointName' property that can be set to 'flex2gateway' for ColdFusion
- Multiple calls to autowire for an object or view will only create mediators once
- handleAutowireEvent ignores flash.* and mx.* classes
- DynamicMediators allow event properties to be null
- Primitive objects can be added to BeanLoaders
- Autowire now supports by type (with [Autowire] instead of [Autowire(bean="foo")])
- DynamicResponder supports passing an array of values to be passed back into the result handler
* for example to have the original saved object passed in to a save result function
- Refactored all bean factory specific functionality out of Swiz and into BeanFactory
- Added Strict flag and MediatorUtils for event type checking
- Added ExpressionUtils, also or event type checking
- Added Prototype object, for non-singleton bean definitions

Swiz updates and documentation!

2008-09-21T11:29:00.000-07:00

You may have heard (certainly not here!) about a little Flex framework I have been working on called Swiz. Although I have been a tiny bit quiet around here, I have been extremely actively developing and using Swiz, as well as traveling out to 360|Flex to do a session, and trying to get the word out on a few podcasts. Well, today I REALLY need to get cracking on the blogging, and luckily I have a few updates to share. First off, I just added a section to the Swiz documentation on DynamicMediators as well as updated the project setup page. Here's a quick rundown of the changes for the week.

At 360|Flex I learned that the Flex 3 SDK will automatically include custom metadata compiled into a library. So now there is no reason to add the additional compiler arguments unless you are using the Flex 2 SDK. Also, there has been a little confusion between the first swc I posted and the latest about how to get Swiz properly initialized. The correct method is to call Swiz.loadBeans( [ loaders ] ) in a function that is invoked in your main application on preinitialize. This will allow Swiz to load all of your beans before any views are added to stage and then autowire your views as they are added.

The major new addition, however, is the new DynamicMediators, which I showed at 360|Flex. Basically this function allows your controllers to respond to event dispatching by just adding an annotation to the function that you would like invoked. Check out the documentation for a full explanation. In the coming weeks I am going to put together a short series of blog posts walking you through the setup and usage of Swiz, but for now, head on over the the google code site, and if you are interested, join the user group and provide feedback to help Swiz grow!

Big news from ColdSpring!!

2008-09-12T06:22:00.000-07:00

I've got big news for everyone on this fine September day! Really big news! I know many of you all have been patiently waiting for the final release of ColdSpring 1.2. Well after a long time of tweaking and testing, the team has delivered! I am proud to announce the public release of ColdSpring 1.2!! But hold on to your hats, that's not the only announcement today! When you head on over to www.coldspringframework.org to download 1.2, you will be pleasantly greeted with a brand new site!!!

Congratulation and a huge thank you to everyone involved! I'd like to especially thank Rachel Maxim (Lehman) for the awesome work on the site design, Kurt Wiersma for the Mach-ii powered implementation, Adam Lehman for the hosting, and Brian Kotek for documentation, bug fixes and general leadership in this release process. Awesome work everyone! Enjoy!

Philadelphia CFUG meeting, this Thursday on Swiz!

2008-07-08T05:27:00.000-07:00

Sorry for the delayed post, but our next meeting will be THIS thursday, July 10th at Huntsman Hall at Wharton. This week I will be presenting on the Swiz Framework for Flex development at the Philadelphia CFUG. You can read the details here, but if you around, drop by to get an introduction into my new Swiz Framework!

Joe Rinehart's Nuts!!

2008-06-27T19:24:00.000-07:00

OMG, I take one week off the blogsphere to catch up on work after cfUnited (I'll get a wrap up soon, but all I have to say is GREAT conference this year...) and Joe goes CRAZY! I'm still reading but he's posting some seriously good stuff in his aptly titled Hiberailooving series. That would be Hibernate+Railo+Groovy. VERY good reading! Covers two major things I came away from cfU with this year, must learn Groovy (reading a great book thanks to Joe) and Railo is very sweet!

Thanks Joe!

Post cfObjective decompression

2008-05-05T18:11:00.000-07:00

Another cfO has come and gone, and once again it was a completely incredible event. I tried to see more sessions this time around, since I usually get caught up in conversations in the halls, but I'm not sure I was entirely successful. Of course, for me all the networking is what it's really all about. Friday night I sat with Sean for a while and had a really interesting conversation about his soon to be release Edmund framework. I had already marked his cfUnited session as a must see, so now I am really excited. Mark Mandel and I spent quite a bit of time together this time around exchanging clothing and planning world domination, er, I mean further work on coldspring's tools for remoting with Transfer, so hopefully the fruit of those long evenings will come quickly.

Of course, what I was particularly excited about was the amazing buzz at the conference about my new Swiz Framework for Flex, which I was able to release to google code on Saturday. Many people asked me to see examples, and a slight oversight with time management in my session gave me the opportunity to show Swiz to a large audience. Overall it seemed very well received. Afterwards I sat with Maxim, Laura and Nahuel looking over each other's source code and sharing ideas. This had to be the top highlight of the conference for me. Mate looks really interesting, and both Laura and Nahuel are amazing AS programmers. Really awe inspiring work. I have been reading their blog for a long time now, and it was just a real pleasure to share some time with them.

I am sure it will take quite a bit of time to decompress from cfO this time around. It seems every year Jared and Steven take it up a notch, which continues to amaze me. I went to quite a few conferences this past year, and none come close to cfObjective in terms of the top quality speakers and session. This year really seemed to be exploding at the seems. I'm not sure I can even take it all in. So long to all my friends until the next conference, I am sure I will see many of you at cfUnited in a few months, thanks for a wonderful time!

Congratulations Jared and Jenna!!!

2008-04-20T18:02:00.000-07:00

Elisabeth Pearl Rypka-Hauer ROCKS!

Possibly my last ColdSpring update this weekend...

2007-11-25T09:53:00.000-08:00

At least I hope so, my fingers are getting tired! This last update is a little on the experimental side, but I have just committed AbstractAutowireTransactionalTests to cvs (CSP-89). Basically this works exactly like AbstractAutowireTests, except that it begins a transaction before each test and rolls it back after the test, unless you call setCommit() somewhere in your test. Like AbstractAutowireTests, you just supply the location of your config file, and setters for any beans you want to test. From there, go crazy inserting, updating and deleting things in your db, after the test everything is rolled back. This is so handy, we use it all the time (I know, I said that about AbstractAutowireTests, but what can I say? They are REALLY useful!).

Just a few things I need to point out. I took a very, very heavy handed approach to making this work. It's not going to be the fastest because Paul creates a new instance of your test class for each test method. At that time (in setUp()) I am doing some crazy proxying and method injection. I am actually creating a proxy, and then taking it apart, it's a bit on the nuts side. However, if Paul would make a tiny change to cfcUnit, I could clean a lot of that up. Anyway, I hope this one is even more useful than the last, and feel free to send bugs along to the coldspring list. Enjoy!

Even More ColdSpring Updates!!

2007-11-24T13:25:00.000-08:00

Ok, this is something my coworker Cliff Meyers has been trying to get me to write for ages. We use the Spring equivalent of this literally every day. Now, unit testing ColdSpring managed beans is not really all that hard, all you need to do is create a bean factory, load your config file, and call getBean() for anything you want to test. But you know what? That's too much work! Enter AbstractAutowireTests, which you will find in the new coldspring.cfcunit package (yes, I do intend to make more!). Here's how it works, extend this class instead of Paul's TestCase, override the getConfigLocations function, and that's it, everything else is handled for you! Oh yeah, this is an Autowired test case too, so just add setters for whatever bean you want to write tests against, VERY handy. Here's an example of a test case using this new component:

A few things to point out here. Right now setConfigLocations is not 100%, it only works with 1 config file, but I will have that done any time now. Also, paths are difficult with cfcUnit as far as location of your config file. Using GetDirectoryFromPath(getMetaData(this).path) ensures that I can refer to a path relative to the cfc being tested. And finally, I am using setUp and tearDown, which are called by cfcUnit's test runner to preform my own set up and tear down actions, so instead you should use onSetUp and onTearDown, which will be properly called by the AbstractAutowireTests. For me, this has been an incredible time saver at work, so I hope you enjoy and find this useful! Now if Paul Kenney answers my email I have even more to commit. Cough, cough...

More ColdSpring updates!

2007-11-24T05:48:00.000-08:00

One thing I love about Spring is every once in a while you wish you had some special type of bean only to find that Spring already has it. Collection factory beans are some of these types of objects, which I actually use quite a bit at work. Let's say you have configured a component you use across many of your applications, so you put its configuration in a base file and include it in each application with ColdSpring's <include> tag. This is a great approach for reusability, but if you want to use arrays or structs to define application specific parameters to that component you're stuck. A lot of times we end up creating special 'config beans' so we can use the ref tag, but many times these are just wrappers over structs anyway. Why use that type of component at all, if you could just define a struct in your config file and reference it wherever you need it? Well, that's the point of the collection factories. Here's an example of these two new components at work:

First I have a ListFactoryBean instance, which you need to remember from spring semantics will return an Array.

<bean id="list.factory" class="coldspring.beans.factory.config.ListFactoryBean">
   <property name="sourceList">
   <list>
   <value>one</value>
   <value>two</value>
   <value>three</value>
   </list>
   </property>
</bean>

And now here's a MapFactoryBean, which will return a Struct:

<bean id="map.factory" class="coldspring.beans.factory.config.MapFactoryBean">
   <property name="sourceMap">
   <map>
   <entry key="one">&tl;value>hello&tl;/value>
   <entry key="one"><value>world</value>
   </map>
   </property>
</bean>

Now I can use the ref tag for these maps and lists instead of directly defining them.

This may seem like a lot of extra xml, but it can really help with configuration reuse, or providing simpler mechanisms for overriding properties for unit tests. Of course if you find yourself wrapping structs or arrays with components just because you are working with ColdSpring, well, now you don't have to.

Long, long awaited ColdSpring updates!

2007-11-23T17:56:00.001-08:00

Ok, it's been a while I admit, and I have been pretty damn quiet up in this here blog, however, I have a serious new goal. That goal is a ColdSpring 1.2 release, and it's going to be SOON!. So, to that end, I'm just going to post my activity so you know where we're at.

I have committed 2 fixes that should make Mark Mandel and Barney B really happy. CSP-84 has been fixed, which is a problem where setting lazy-init to false does nothing at all. (Ooops it was never implemented, sorry...). You can now define the lazy initialization on a per bean basis with the lazy-init attribute, or set the global default by specifying default-lazy-init on the root bean element. CSP-83 was a semi bug that actually resulted in extraneous try/catching, but basically I had a bug that made it a little difficult to create custom factories. This is different than defining one bean as a factory for another bean with the factory-bean attribute. If you register a bean that extends coldspring.beans.factory.FactoryBean, that bean will automatically have getObject() called on it when you call getBean(). This can really come in handy for some advanced configuration. I know Mark Mandel was working with it, but ran into some bugs. But it is now fixed, happy day!

OK, that's it for right now, there is A LOT more to come...

Flex 3 beta Now on Labs!

2007-06-11T05:00:00.000-07:00

Well, that pretty much sums it up, Flex 3 aka AIR (not too sure of that codename myself!) is now available on Adobe Labs. It sure looks like the RIA space is really heating up now. I know a lot of Flex developers have had harsh criticism on MS Silverlight, and based on current tools alone, I would say rightly so. But the fact of the matter is, MS has arrived at the party. There was also a very interesting exchange in the interview with Bill Gates and Steve Jobs where they discussed the importance of RIAs, both clearly stating that their companies where committed to the idea of richer applications connected to what they called the 'swarm', I believe. And today, we have a brand new beta of Flex, Adobe is clearly leading this market right now, it's so exciting to see the technology pick up in pace! So get yourself some air and enjoy!

cf.Objective() session updates

2007-03-26T18:10:00.000-07:00

I finally got my sessions to Jared, and he has posted an updated list. I'm going to be doing an introduction to AOP as well as a session concentrating on using ColdSpring to power your Flex applications. Don't forget, early bird pricing will end April 1st, so you better get on your tickets quick! Honestly, $395 is an absolute steal for the amazing amount of top notch sessions that your going to be getting. Last year cf.Objective() was no doubt the best CF conference around, and this year it looks to be even better, so go register! Right now!

I am also bringing my Flex/ColdSpring session to CFUnited, which is also shaping up to be another great conference, so go register for CFUnited too! Honestly, the value of conferences like these cannot be measured. I got my shinny newish job at Cynergy Systems through contacts I made at CFUnited last year (along with Dave Carabetta). If your looking for the best way to advance your career with marginal expense, these conferences are surely your best bet. See you there!

Unlocking the power of CF Metadata

2007-01-29T17:09:00.000-08:00

Lately I have been thinking an awful lot about metadata. We have this great metadata object in CF, but I rarely hear anything about it. Funny, even though we use metadata extensively in ColdSpring, I sort of forgot it was there for day to day use. ColdFusion's metadata object is free for the use in almost any way we want, and can provide extremely powerful class or method level annotations. Let's take a quick look at an example so you can see what I'm getting at. Write yourself any cfc, and write a simple cfm page to dump it's metadata:

This will output a big struct with all sorts of information about your object, like its name, extends, path, and lots of information its functions, like name, access, etc. There's a whole lot of great information for you to use, but what's really cool is, you can put your own stuff in there. Just make sure you don't try to overwrite any attributes that ColdFusion uses. This can be easily accomplished by using a prefix to create your own namespace. For my examples we'll use 'cs_' for our attributes. So lets add some custom metadata to our cfc. In the cfcomponent tag, lets add an attribute 'cs_metadata="really cool stuff"' (<cfcomponent name="mycfc" cs_metadata="really cool stuff"...) and run the cfm page we made in the previous example. Check out the output, now we have a cs_metadata key with the value "really cool stuff". Really cool, huh? Or are you thinking, so what? The thing that got me all excited about this is, if we use annotations on methods in our cfcs, we can access them in Advice components (you knew I was gonna get to some AOP right?), which is in fact really really cool stuff.

The great thing about AOP is it gives you the ability to develop abstract systems in an extremely generic manner. But when we apply them to specific components, we want them to take on more concrete functionality. The easiest way to do this is to provide your Aspects with parameters during configuration, enabling them to become more specialized to your components. For example, in the Klondike record store example I have been showing in my sessions, I have a generic caching system which can be configured for each type of component to cache by providing information to the Aspects. But the downfall of this is, I have to configure that Aspect over and over in ColdSpring for each model component. Enter metadata!

Let's take a look at a super simple system, one that always show up in any AOP conversation, logging. It's pretty easy to write a very general logging system. I like to wrap the logging in a service so we can reuse it anywhere, and provide log level methods, info(message), warn(message), error(message), debug(message), this way I can swap out cflog for log4j and control the log level in one place. Now all we need is an Aspect that will build a log statement from a method call. What if we would like more control, say to only include certain parameters for certain methods. This would be a nightmare if we tried to provide some sort of configuration to the Aspect, but we can easily put this info in the function metadata and read in in the Aspect! Here's how it's done, first we'll add some metadata to a cfc that we want to log method calls, notice I have added a cs_LogFields attribute:

<cfcomponent displayname="EntryService">

  ... init method and setters for dependencies ...

  <cffunction name="getEntriesByCategoryID" access="public" returntype="array" cs_LogFields="categoryID" output="false" >
    <cfargument name="categoryID" type="numeric" required="true" />
    <cfargument name="numToReturn" type="numeric" required="false" default="-1" />
    <cfargument name="activeOnly" type="boolean" required="false" default="true" />

    <cfreturn variables.entryGateway.getEntries(arguments.numToReturn, arguments.activeOnly, arguments.categoryID) />
  </cffunction>

  ... more service methods ...

</cfcomponent>

Next we have our logging service, I've used cflog in this example and added a setter for the log file name.

<cfcomponent displayname="LoggingService">

  <cffunction name="init" returntype="net.litepost.component.logging.LoggingService" access="public" output="false">
    <cfreturn this />
  </cffunction>

  <cffunction name="setFilename" access="public" returntype="void" output="false">
    <cfargument name="filename" type="string" required="true" />
    <cfset variables.filename = arguments.filename  />
  </cffunction>

  <cffunction name="info" access="public" returntype="void" output="false">
    <cfargument name="message" type="string" required="true" />
    <cflog file="#variables.filename#" type="information" text="#arguments.message#">
  </cffunction>

  ... rest of logging methods ...

</cfcomponent>

So now we will need an Advice class to tie it all together. I am going to use an AfterReturningAdvice for this one, it's going to be a bit more complex, so I'll put some comments in line.

If you've followed any of my previous AOP posts, you should have no problem setting all this up in your ColdSpring config file. I'll also include those links. This may look a bit complex at first sight, but look what we are gaining now. I could have provided setters to my advice class, allowing the application developer to configure it to specific uses, but that would mean they would need to configure this class over and over again for each different use, as I did for my caching system. By creating my advice class to read metadata, though, I have still provided that same customization, but this time with minimal work for the developers. Plus, we have provided the power of configuration right where the developer is working, in the cfcs themselves. This may not be the best way to go for all systems by any means, I still feel that the real power of ColdSpring AOP is its declarative approach, and it can be argued that this is going in the opposite direction. But the sheer power of this approach can open many doors to designing truly generic systems. For me that is the ultimate goal of AOP.

Happy programming, and I hope to see some readers at the frameworks conference where I plan to get a lot more in-depth into these concepts both in my session and drinking in the bar! See you!

Introduction to ColdSpring AOP
ColdSpring AOP Tutorial – Part One
ColdSpring AOP Tutorial – Part Two, Around Advice
Introducing auto-magic Remoting with ColdSpring

I'm the quintessential CF Developer!!

2007-01-26T10:59:00.000-08:00

WOW! I can't believe it! I'm actually the quintessential CF Developer, as far as Tim Buntel is concerned! He was a little off on his meme though, so I thought I would update it, make it a little more accurate:

Chris, the web developer persona

38 years old
Married for 7 years, has a 5.5 year old son named Tommy and a 3 year old named Simon. They both are insane about Star Wars Legos
Drives a 2004 Honda Accord (which the wife stole), 1998 Volvo V70, and 1999 BMW r1100s (which is the greatest feat of engineering ever created. And it's yellow, oooh yellow...)
Bought a house a 6 years year ago, a 1885 Stone Victorian, slowly renovating. Decorations are partially vintage, but not really.
Likes the "I'm a Mac, I'm a PC" tv commercials, hates the UPS "Whiteboard" ads. OK, Right on 100%. Except I like the PC guy and the Mac guy is a pompous twit. But I have been a hard core Mac enthusiast my whole life. Hey we had a Lisa for christ's sake!
Couldn't give a rat's ass about the Oscars
Into How It's Made, Mythbusters, secretly watches American Chopper even though I hate it, random nature and science stuff
Likes snowboarding. Wait, really likes snowboarding, really. I actually started when they were planks of wood with a rope on the nose and freaking water ski bindings. (And yeah, we wore an onion on our belt)
Food? A little bit of everything, especially if it's on the grill
Music? Let's put it this way. I added American Hardcore to my netflix queue last night, and am giddy as a school girl waiting for that damn movie to actually come out on DVD. Seriously I cannot even believe I missed it in the theater. And the new Slayer is AMAZING
I lost a lot of hours watching Devo videos on youtube. I do not know why...

Help Tim, what's your persona??

Some Excellent Flex articles...

2007-01-26T10:04:00.000-08:00

Kind of late on this, but in case you missed em, a couple of Cynergy coworkers / Flex super gurus have written some must read flex articles you probably want to check out.

First up, Andy Trice did a killer mashup with Yahoo Maps and StrikeIron's census web service. Really cool demo, and of course Andy's blog is pretty much a must read.

Andy and Keun Lee also wrote a great article, second in a series on Building RIAs from front to back at Adobe's Dev center. Part one was also written by Carson Hager and Dave Wolf, Cynergy execs and killer developers too. Some really great stuff.

Happy New Year! (From ColdSpring too!)

2007-01-01T09:45:00.000-08:00

Happy new year everybody! Or should I just list out my limited readership by name? 2006 was a very crazy year for me, good in a lot of ways, completely crazy in others, so good riddens, but only sort of. I thought that today would be a really good day to sit back and relax, but instead I decided to work on some ColdSpring. Oh well. I'll relax later. So does that mean there's something new to announce? You bet! And you can thank Sean for bugging me, too. ColdSpring now supports the tag! Here's how it's used:

Lets say you have a bean defined, perhaps a reactor factory like the following, which you have referenced all throughout a complex configuration file:

<bean id="myReactorFactory" class="reactor.reactorFactory">
    <constructor-arg name="configuration">
        <value>/config/reactor.xml
    </constructor-arg>
</bean>

Now let's say you have switched architectures to something like Model-Glue:Unity, and you want to use that same reactor factory. But there is a problem, because Unity wants that bean to be named 'ormService'. Previously you would need to change the bean's id, and then all the bean ref tags, but now can just simply define an alias, like so:

<alias name="myReactorFactory" alias="ormService"/>

Walla! Done and done. Now that's just damn handy! This is still a work in progress, so feedback and testing would be great. Happy New Year (again)!

Thank you Pennsylvania!

2006-11-07T19:14:00.000-08:00

The concession speech has just ended, and for the first time in many years I can finally again be proud of our political process. Having Santorum for a Senator of the state where I was born and raised has certainly not been something to be proud of, but we can all breath easy and be a little happier. Thanks again PA!

New Job's Resolution...

2006-09-08T19:13:00.000-07:00

Rock! I simply could not help myself, isn't she a beauty?

Congratulations Paul and Adam!

2006-08-15T10:52:00.000-07:00

In case you haven't heard, Adobe has aquired two great members of our community, Paul Kenney and Adam Way[ne Lehman]. Read about Paul's job with Sean, and Adam's new job as North America's new ColdFusion Specialist (that's a hell of a title Adam!).

Best of luck to both of you!

One ColdFusion 8 wish...

2006-08-11T17:21:00.000-07:00

There's a lot of good lists out there, and sure I've got a few wishes, many of which have been said before. But there's one in thing I don't think anyone has mentioned that I really think would be incredibly useful. I would like to see better packaging options in CF 8. We can package up applications along with CF and deploy them as ears, which is great, but I'm more talking for library code. What I would really like to do is just have modelglue or cfcunit as a .jar file, drop it in a mapping or custom tags directory and be all set. This has nothing to do with trying to 'lock' the code mind you. Take cfcUnit for instance, Paul has a packaging structure of org.cfcunit.*, which is all fine, except for I have a client who's packages also start with org. So I can either create a mapping for org, and put both sets of code in there, or make a specific mapping for org.cfcunit. Personally I think it would be a hell of a lot more flexible to just be able to use .jar files and skip the mappings. CF should be able to figure out what's where by the manifest files.

Going to MAX 2006?

2006-08-03T17:25:00.000-07:00

I'm trying to get my travel plans together quick so I can get a decent price on a flight, but even though the discount on rooms is very good, they still don't come cheap! So I'm looking to share a room, any takers?? If you're interested, post a comment, or hit me up on IM (my gmail address is on my resume, check the hire me link).

I like to stay up very late and I think I like beer, so take that into account...

Thank you Paul and John Paul!

2006-07-30T18:12:00.000-07:00

You know it's been a while since I had one of those days where I truly had a great time writing code. Could be all the Java I've been working on these days, or maybe a few other reasons, but I've been feeling a little bogged down lately and it sure was nice to have a fun time coding again. So why was yesterday so nice you may ask? Well I'm back to some contracting work that I was working on last year on a well designed system written in ColdFusion, for one thing. And it's been quite easy to jump right back in to the system, which in itself is a testament to good design. But what made yesterday even that much better than the breath of fresh air which is working with ColdFusion was a little gift that Paul Kenney sent me the other day. I know, Sean has already told you about the wonderful new cfcUnit with Ant integration, brought to you via John Paul Ashenfelter, but I simply must sing it's praises again! Now I am a huge believer in TDD or Test Driven Development. JUnit is a big part of my development cycle these days, and I do try to use cfcUnit as much as I can. But to be honest, unit testing in cf has been pretty far behind Java, and the main reason is the fact that I want to test while I'm coding, immediately. Having to deploy (unless you work locally out of a web root), and then go to the cfUnit test runner app, and then load my test case there, well, it's not exactly the greatest. But it is worth it, so I do it. Until now...

So I finally deployed the new version of cfcUnit and stuck the ant-cfcunit.jar somewhere easy, in an ant-cfcunit directory in my home folder, btw, put together a quick build script and, well a few minor glitches, but 15 minutes of tinkering later... cfcUnit tests! Right there in eclipse! And some nice simple output in the console! This is freaking great! (Can you tell I'm excited, btw?) But really, I'm working on very broad changes to the model in this app, top level logic changes that will effectively make changes all over the codebase. So I want to pretty much work in isolation right in test cases before I put these components into the model and check them inside the app logic. What I want to do is work in complete isolation of the rest of the app, and test at a very fine grained level. The great think about being able to do this right in eclipse is, all I have to do is start the cf server, but I never have to leave the editor. Even though running tests from the test runner app is still outside of the application, this just feels so much more natural, and, well, I guess more like JUnit. So thank you so much Paul and John Paul, much kudos to you!

Since it would be helpful of course to show how this is done, here we go. As I said, I deployed the new, soon to be released cfcUnit to my app server, and put the ant-cfcunit.jar in /Users/Chris/ant-cfcunit/. My build.xml file looks like so:

Next, open up the and view, load the build button and hit the little play button, and watch her go! You can see I have the verbose version set as the default, and can change to a simple version if I need. Also, I have set up a test suite, and each time I change a cfc, I write a test case and add it to the suite. So there you have it, now go and test!

mysql quick-tip

2006-07-15T09:41:00.000-07:00

I just ran into an issue with rebuilding a mysql database for development, moving the database from a windows server to a linux one. By default windows mysql converts tables names to lowercase, when I imported the database onto my linux server all the filenames for the tables are also of course going to be lowercase. Unfortunately all of the app's queries refer to the tables with camel-case, probably the intention in the first place. Problem is, now my linux mysql instance cannot find any of these tables, because the filenames are lowercase. So how do we fix this? Well, luckily we can start mysql with the flag 'lower_case_table_names', set it to true and mysql will now force tables name to lowercase just like in windows:

[chris@myFC4box ~]$ sudo mysqld_safe --lower_case_table_names=1 --user=mysql

Hope that helps if anyone else gets in this bind!

Pointcuts, even more fun with regex!

2006-07-10T19:41:00.000-07:00

Ok, so maybe 'fun' isn't the right word, but I have to say that I though it was pretty damn cool the first time I swapped out a pointcut for a regex one (yesterday)! Incase you're already wondering what the heck I'm blabbering on about, currently ColdSpring has a pretty simplistic pointcut model, you can only really define them as globs, strings which can contain the '*' wild-card. Simple, yes, but in that simplicity lies tremendous power, which is what I find so fascinating about AOP in the first places. So currently we can match all the set or get methods in an object by defining a pointcut with the mappedName 'set*' or 'get*', and just for a refresher, we would do that by creating an advisor like so (here we are providing a cachingAdvice):

Here we are defining a NamedMethodPointcutAdvisor and providing it a list for mapped names, get* and set*. Side note, the <list> element in ColdSpring refers to a CF Array, following the Java DTD, to use a CF List provide a string list as a <value>. Behind the scenes, ColdSpring will create a NamedMethodPointcut, and provide it with the mappedNames value. This pointcut is what the framework will use to preform the method matching in order to identify the methods that you would like to add, in this case, the cachingAdvice to. So this is all very good, but what if what we want to do is add caching to all the methods EXCEPT the getters and setters. Ahhh, enter the RegexMethodPointcutAdvisor, which as you would probably guess, will create a RegexMethodPointcut. So lets see how that will look, with a pretty complex regex pattern to match all methods except the setters:

So as you can see, we are defining a very similar advisor, but this time we provide a property called 'pattern' which will be our regex pattern. This one's a bit complex as we need to use negative back referencing, which honestly is a bit confusing to me, but google is your friend! But the great part is now we can define methods to exclude from matching, which is tremendously powerful. Want to look for getters and setters? Use this pattern ^((?![g|s]et).)*$ and you should be fine.

The two new components, RegexMethodPointcutAdvisor and RegexMethodPointcut are available via cvs. Happy AOP'n!

CFUnited wrap up, Unit Testing and RHH…

2006-07-02T14:56:00.000-07:00

I just got back from a nice long ride to clear my head and shake out few neural passageways that seemed to have somehow become clogged with alcohol and lack of sleep, so I figured I would share my thoughts on the festivities of the past week. CFUnited was fantastic and I had a really, really good time, maybe even too good, I’m TIRED! As far as sessions go, I think my 2 favorites were Adam Wayne Lehman (aka. Adam Way)’s talk on security and Dave’s talk on ColdSpring. OK, I know it sounds very partial, right? But Dave was truly amazing; he’s a top-notch speaker and came prepared with an enormous amount of information, which was very well put together. He took his time with the material, and was even able to answer questions while going through the session and still make it through all his slides without rushing. Somehow or another he was able to squash a talk about AOP into 15 minutes and 1 slide and still have it make perfect sense. Dave’s a valuable member of our community and great leader for the ColdSpring project in general. While we’re on the subject of value, I don’t think a single person of any skill level didn’t learn something at Adam’s session on securing CF applications. Adam has a unique experience dealing with security issues in a very tight environment (Department of State), and went through an amazing amount of information, from designing baseline installation documents, to securing your OS (even Windows), to working with CF’s sandbox security. He went on to discuss how to attempt to prevent DoS attacks, and the importance on keeping on top of not only ColdFusion, but also JRun security patches, as well as using the setting in Application.cfm/cfc. Just kidding, it doesn’t exist. Put your documentation away. Unfortunately right as he was discussing a bunch of different cross site scripting attacks, my wife called twice, and I had to leave, so I hope to be able to catch that session again at some future conference. Other sessions worth noting were Paul Kenney and John Paul Ashenfelter’s pre-conference session on Unit testing, and John Paul’s session on Agile development process, which generated quite a stir at the conference. I heard many people talking about the session, even though I missed it. Of course, Sean’s sessions were great, but I have already seen them both, so for me they didn’t garner up as much excitement as the aforementioned. Don’t take that as any recommendation against seeing Sean speak, because you would be doing yourself a great disservice.

OK, so aside from the sessions, I think one of the most important things I saw at the conference was the prevalence of discussions about unit testing. I talked with many people about how and why we should be unit testing our code. One thing that I repeatedly kept talking to people about however, was trying to write unit tests as early as possible, and not only because it is harder to write tests after your complete large pieces of application code (as you may inadvertently skip functionality that should be tested). In order to be able to write unit tests against individual objects in your model, those objects need to be as self-sufficient as possible, or they are not testable. This is a central concept in what is know as Test Driven Development, where testability is actually designed right into your components. It only takes a second to realize that when components are designed for testability, they become more cohesive and more loosely coupled. For example, lets say we are working on a DAO, and we access form variables in our queries. Well, this DAO is now completely un-testable because it is dependent on the form scope, which means it can only be tested in a running application. How about a service component that retrieves data from a Mach II or ModelGlue event object? Again, we can’t effectively write unit tests for that service because it is dependent on those frameworks. In Dave’s ColdSpring session, he discussed the problems associated with what he called a ‘brittle domain model’ where components are too dependent on other components to get their job done. These types of components are also much harder to unit tests, because you need to create a complex web of objects just to run a test. One of the other big problems with testing complex, dependent model components is, what you end up creating as a test case, is really a q/a type test on use cases. You are testing how a large dependency chain works in what you feel is the real world of your application. But when a small thing needs to change and begins to alter functionality deep down in your domain model, you have very little in place to reflect and catch those problems. As a case in point, within the past month on two separate occasions I made some changes to model objects that made my unit tests fail. I now tend to build unit tests for every single object, and then more unit tests for groups of objects returned as services from Spring. I then build all of those unit tests into one big test suite that I can run when I make some changes, and I can tie them into my build process. Anyway, back to my point, when I made the initial changes, I had introduced some issues that caused problems in other parts of my model. Now the thing is, I would have never caught these problems until q/a, which would have really sucked. One of these issues in fact would have only caused problems some of the time, making it really hard to test and find. However, these changes failed in the unit tests. You’re probably wondering how that could be, and here’s the thing. The components held themselves up when tested together, as services, because they supported each other (and ended up being a little brittle, I suppose), but the tests written against the components themselves actually tested the objects in ways that my application doesn’t necessarily function, making them really effective. The end result was I was able to fix both problems within minutes of running my test suite, but who knows how long debugging would have taken during q/a. Even though it definitely takes extra effort up front, I would strongly suggest looking into unit testing as early as possible, and also do some general research on test driven development, or TDD, there’s some great stuff out there.

Oh, one last thing about that, as I have discussed, TDD lends itself very nicely to developing more cohesive and looser coupled model components, which just so happens to play very nicely with ColdSpring, which encourages the same thing by decoupling your model components from their dependencies. Wait, you may be thinking, if I decouple my model components from their dependencies, how do I put them together to test them? Well, it only takes 2 lines of code in setup in a test case to load a beanFactory, and just one more to retrieve a bean. As I had also mentioned before, try to test components by themselves as well as with all their dependencies resolved by ColdSpring, it really helps show their weaknesses!

Happy testing! And oh yeah, RHH!!!

24hrs till CFunited! (Sort of)

2006-06-25T12:02:00.000-07:00

Well, cfunited is actually 2 days away, but I'm driving down tomorrow to meet Paul K and Adam L (sounds like spy names or something) in Bethesda. I'm speaking at DoS on tuesday, and it's Adam's birthday, so I think the cfunited festivities should start a little early! I'm definitely looking forward to a really fun week, there's a lot of great sessions, and lots of really smart people to hang out with and try to leach some brain power off of!

I also would like to extend the open invitation to anyone interested to have some adhoc bofs on Aspect Oriented Programming, I'd be happy to do my presentation from cfObjective, and although I haven't asked him, I'm hoping Simeon would take part, because he's been doing some really fantastic and cutting edge stuff with AOP and flex these days.

OK, can't wait to see everyone there, and oh yeah, if anyone is going to be around BWI tuesday at 3ish and wants to pick up Dave Ross so he doesn't have to take a bus down to the conference, that would be really great. I'm not sure I can make it up there and back for the speaker dinner after the DoS thang...

Go watch this and see your head spin wildly!

2006-06-09T14:53:00.000-07:00

Check out this completely nutty video from Joe Rinehart demoing the new ModelGlue Unity. It's completely insane!

For those of you who don't yet know, Unity is a wonderful marriage of the ModelGlue, ColdSpring and Reactor frameworks, which WILL change a huge amount of the landscape for many ColdFusion developers. Enjoy, and thanks Joe!

ColdSpring 1.0 RC1!

2006-06-02T14:21:00.000-07:00

Well, I think it looks like I'm a little late to the party, because blogger SUCKS and I couldn't log into my own freakin' blog all day, but...

I'm extremely happy to announce the availability of ColdSpring 1.0 RC1! It's a bit overdue, and of course there will probably be a small wait for the final release, but things seem to be very stable at this point. So please, download the latest and provide some feedback to the list!

PS, anyone wanting to donate some sweet server goodness to host a nice little mg4j blog app so I can move this damn thing, I'd be soooooo happy!

Flex 2, MG4J, and Spring. Bliss...

2006-05-25T19:17:00.000-07:00

Perfect timing! I just read this post on Sean's blog, about some of the pitfalls of building Flex front ends for existing Mach II apps and started to write a comment, but it got too long. So I figured I'd just post it. I'm currently working on a big conversion of an application from a very evil and horrible framework to ModelGlue/Spring and Flex 2. This one's Java, but really that's circumstantial at this point, everything is pertinent to CF. I thought it may be an interesting read to write out my development process for this project, so here goes...

I started by flowcharting everything the current app does, and putting names on each bit of data access that is descriptive (this app is bizarrely procedural in its current form!). From there I could identify what my Services would look like, and what methods they would need. That's pretty simplified, but it was almost that easy... Next I defined my DAOs and in certain places I created custom query objects. Too hard to explain, but there's some pretty hard core business logic about HOW to query for data in a lot of cases. Pretty much at the same time I designed the Domain Objects that I would be using at a higher level, raw data in more fine grained views.

OK, next step, test like crazy! That's not really true, because I tend to write test cases for every Domain object as I create them, then every DAO/Gateway as I create them, then all the Services, when I hook them up in Spring, and that goes on and on... The main point here is that I'm concentrating on building and testing my model alone, and constructing services, because I know I'm going to be targeting both Flex and a normal web based app.

So now on to the MG app. Views, controllers, a security system that is pretty standard to what I've been doing for years... This part is pretty easy, in my MG Controllers, I'll put a bunch of stuff in the event, and then I use it in views. Like every one...

Now I have a nice little MG app, and hey it's in Java and really wasn't too hard to write! Amazing, Spring JDBC was a life savor here, btw... But how does this get into Flex! Luckily since I was thinking ahead, even though I would have done everything this way anyway, accessing Spring managed services from Flex is no big deal. I created remote proxies for each of the services, which look up the Spring bean factory through the application context and then retrieve their respective service bean, then defined them in flex-remote-services.xml. That was well, pretty much it! Then I just wrote the Flex front end, and for the most part, the Java to AS object mapping is perfect. As I got deeper into it my proxies started to look a lot more like my MG controllers, as a single method to the service proxies may call multiple methods on a few different services even, returning data keyed in a hashMap. Kind of like adding data the current event in MG. And that's it, my current development process, and what I've been up to for the past few months. Hope it's helpful!

Today's fluff...

2006-05-11T18:11:00.000-07:00

OK, I liked the idea of Sean posting his all time top played album, so here's a few lists of my own. I was looking at the top play counts for all my music in iTunes, and they're kind of skewed, I think because of the way I listen to music. I'm a big fan of shuffle. But here's some interesting (maybe) things:

Last 5 albums played (because today I didn't shuffle!)

Mastodon - Leviathan, the saviors of the new Metal? Perhaps, but I doubt it...
Minor Threat - Complete Discography, I'm not going to transfer all my $5 records...
High On Fire - The Art of Self Defense, Stoner Metal at it's best!
Born Against - Nine Patriotic Hymns For Children, a huge influence on me...
Gang of Four - Return the Gift, Last year another great 80s band rerecorded their greatest. I simply cannot stop listening!

All time most played Songs:

Orange 9mm - Glistening (Driver Not Included), Used to be the singer of NYC hardcore band Burn, another big favorite
Clutch - Mercury (Blast Tyrant), OK, that's a complete surprise, no idea how that happened
Gang of Four - Damaged Goods (Return The Gift / A Brief History of the Twentieth Century), see what I was saying...
Oingo Boingo - Private Life (Nothing to Fear), another confusing pick there..
The Dillinger Escape Plan - Sugar Coated Sour (Calculating Infinity). Think Praxis, but add more metal. Very odd...

Well there you go, I'm not sure if that's the best representation of my musical tastes, but it's a pretty interesting way to look at someone. What do you like?

Luray, VA, I'm on my way...

2006-05-06T05:43:00.000-07:00

It's 8:45, Saturday morning and I'm about to leave on a 3 day motorbike trip with my pops. 30 W through southeast PA to Gettysburg, where we'll drive around the civil war battlefields and have lunch. Then 15 S to Frederick MD and on to 340 S/W. We maybe will take a break in Harper's Ferry National Park, then we drive to Front Royal, the top of Shenandoah National Park, where we'll pick up Skyline Drive and go about 1/3 the way to Luray. It should be a great long ride, I'll post picks when I return, and maybe on the way. I hope I keep the paint up!

Yeah, I'm a nerd

2006-04-13T18:19:00.000-07:00

Well, I did it at work, in response to reading Sean's post. I wasn't gonna bother putting it on my blog, but after seeing it so much on MXNA, well...

So the ridiculous part is, I tried to answer the all the questions the same, and jumped from 95 to 97. See, it's like it knew I was going to post it after succumbing to peer pressure, and gave me 2 more points!

ModelGlue 1.1 released, 2.0 coming soon!

2006-04-10T17:40:00.000-07:00

Congratulations to Joe Rinehart on the release of Model-Glue 1.1! Joe's been dropping bits of information about the upcoming release for a while now, and I know he's been working really hard, so I'm really happy for him getting this release out. Of course, I have a bit of a vested interest in MG 1.1, because it brings official support for ColdSpring, along with a few other bug fixes.

Along with the news on the 1.1 release, Joe also has declared the end of life for MG 1.x development, because Model-Glue 2.0 is coming, and from what I've heard in dark alleys and late night IMs, 2.0 will be a very exciting release! Funny, at cfObjective, during the frameworks round table (or open source comedy hour) the question came up wether the development of Model-Glue was still active, as Model-Glue seemed to be under represented. Since Joe had been forced to miss the conference due to the fact that he had bought a new house and was a little busy moving, I became the official spokesperson for Model-Glue. I assured everyone that development has been very active, and now you can see why!

It's a really exciting time right now, and not just for Model-Glue. Mach-II 1.1.0 was released recently, Fusebox 5 is in development, ColdSpring is moving closer to 1.0 daily (really!), Reactor 1.0 is almost out, Transfer, Tartan, cfcUnit, you get the point. These are great times for cf developers! Congratulations again to Joe!

40 things about myself…

2006-04-06T11:25:00.000-07:00

Last night my wife got this meme from a friend in Brooklyn. I thought it was a pretty cool way to know some things about your friends that you may not know. So today I hit up Sean’s blog and what do you know? He’s posted it there! So here goes my entry:

Four jobs I have had in my life:

Retail Expert - One of a thousand monkeys
Sealworks - Senior Software Developer
Urban Folk Art - After college I was a struggling artist in NYC for a while, UFA was an art collective and t-shirt company my fiends and I started
Krabloonik - Shoveling dog poop, really. Worked for a summer taking care of sled dogs, and yeah they pulled sleds.

Four movies I watch over and over:

Blade Runner - Probably my all time favorite movie. I've seen it thousands of times
Das Boot
2001: A Space Odyssey
2,000 Maniacs - Although I haven't seen it in a long time, my friends and I used to watch it religiously

Four places I have lived:

Philadelphia, PA
Brooklyn, NY
Providence, RI
Snowmass Village, CO

Four TV shows I love to watch:

OK, so this is tough. I really love tv, but I absolutely hate almost everything on tv right now. I for years believed that tv was a super important artistic device, one that MUST be monitored, at all times. Unfortunately, reality tv has completely destroyed it. So, my 2 cents aside, here's a few:

Simpsons - What's wrong with me! I forgot to put the Simpsons!!!!
Cheers - Man, I watched that show every day for years, and I still catch it time to time. I've had dreams I was hanging out in that bar!
Coupling - Not on anymore, but still, funny as hell.
How it's made - I don't know, it's fun to watch with a 5 year old
C.S.I (I also watched Law & Order for years)

* Side note, I watched every variant of Star Trek...

Four places I have been on vacation:

Czech Republic (Prague and all over Moravia)
Salzburg, Austria (Vienna as well)
Playa Del Carmen, Mexico
San Fransico, CA

Four websites I visit daily:

An Architect's View
clearsoftware.net
MXNA - Shortcut to everywhere else I suppose
www.macromedia.com - I'm all over flex right now

Four of my favorite foods:

Pork Chops
Cheese, all cheese
Svickova Na Smetane - Czech goodness
Almost everything my mother in law cooks

Four foods I dislike:

Four? Man, I really like almost all food, but wait, there is..

Beets - AHHHHHHH, run!
Tuna fish salad
Chicken salad

I like tuna, I like chicken, I guess I don't like mayonnaise!

Four places I would rather be right now:

Czech Republic
Barcelona (forgot to put that on the vacation list)

Ahh, I can't get four, I like where I live, and my job is doing well right now
Four friends who I have tagged to do this! Like Sean, I will just post this, do what you will!

Off to cfObjective!

2006-03-09T17:13:00.000-08:00

My bags are packed, my sessions are prepared, got my travel plans all squared, and I'm ready to go!! OK, actually, I haven't packed at all, I'm totally stressed about my presentations, and I have no idea how to get my eTickets printed out, cuz my printer's all f'd up. But other than that... I am very psyched, it's going to be a great conference! There's still some time for you slackers who haven't decided if you are going to get some tix, so lets go! The speaker list is awesome, the conf is right next to the Mall of Americas so in all your free time, there will be tons to do, right, and the networking opportunities alone are worth double the price of admission. See you there...

Good AOP discussion on The Server Side

2006-02-19T05:42:00.000-08:00

There's a really interesting thread on The Server Side, for anyone interested in AOP and wondering where they might want to use the technology. The original article discusses some the many myths and realities around AOP, also interesting reading. I particularly liked the comment by Bela Ban about how AOP is used in JBossCache, it's a good example of how tool developers are using AOP to create maintainable code in a very abstracted system. On the flip side, about a quarter of the way down there's a good stab at the highly confusing terminology involved with AOP. Very timely for me, because I had a heck of time talking through this with Judith Dinowitz this week, and one of the points I tried to make was that the biggest stumbling block for anyone getting into AOP is probably going to be the terminology. In practice, I think using AOP can be far simpler than in sounds, especially when used with an IoC container like ColdSpring, or Spring for Java. Sometimes I wonder if technologies in Java are purposefully discussed in a very confusing manner, just to keep the faint of hart at bay so the 'gurus' can closely guard their precious secrets. Yet another reason why I like ColdFusion so much, where even very advanced concepts can be discussed in human terms!

Introducing auto-magic Remoting with ColdSpring

2006-02-12T11:11:00.000-08:00

This is kind of a mix between some features that have been available in the ColdSpring BER and some new additions to the AOP framework. Not only is this a kick ass new feature, but it’s also a collaborative effort of Kurt, Dave, and myself, with lots of input from Paul Kenney and Sean Corfield. So kudos goes out to everyone involved! Here’s a general overview of what auto-magic remoting means. Let’s say you have a service component registered with ColdSpring, which does some database access for some piece of a web app. What if we want to take a few of the methods of that service and make them available as remote methods for a flex app, or a web service. Wouldn’t it be nice to simply add a component to the ColdSpring config file that has a list of methods you would like to expose, that will automatically configure itself to your service component, expose those methods as remote, taking care of the CFC to AS object translation for you? How about if you could also simply plug in a security through AOP as well, and pretty much write no additional code at all. Well, that’s exactly what ColdSpring Remoting is all about! So let’s see how we can do this in practice. We’ll start simply, with the configuration of a remote facade, or proxy (it’s sort of a little of both) for a service component, then we’ll add the CFC to AS object translation and finish up with some security. Here’s our service, it’s from the klondike records application available in the BER, in the examples folder.

<bean id="catalogService" class="net.klondike.component.CatalogService">
    <property name="catalogDAO">
        <ref bean="catalogDAO" />
    </property>
    <property name="catalogGateway">
        <ref bean="catalogGateway" />
    </property>
</bean>

I won’t go into the code for the components, but this service has methods for listing, searching, adding and updating records (as in vinyl, not tables). I would like to create a remote façade to expose the ‘list’ methods, which would be any methods starting with ‘get’. So I’ll configure a RemoteFactoryBean which creates a proxy, writes it to disk at a specified location (so that the ColdFusion flashGateway can find it) and I’ll tell it which methods to include, which will have ‘remote’ access. Here’s the config:

<bean id="remoteCatalogService" class="coldspring.aop.framework.RemoteFactoryBean">
    <property name="target">
        <ref bean="catalogService" />
    </property>
    <property name="serviceName">
        <value>RemoteCatalogService</value>
    </property>
    <property name="absolutePath">
        <value>/usr/local/cf7/htdocs/klondike/machii/remoting/</value>
    </property>
    <property name="remoteMethodNames">
        <value>get*</value>
    </property>
</bean>

I set the target to the service cfc I already configured, I give this remote service a name and an absolute path (I could also have used the property ‘relativePath’, meaning webroot relative) where I want the RemoteFactoryBean to create the service, and I give it a pattern to match methods on, so in this case all methods that begin with ‘get’ are included as remote methods. That’s it! When ColdSpring starts up, I can ask it to create the service (I’ll get into that part later) and I’m done! No code written at all! This new remote service will now be available at www.yourdomain.com/klondike/machii/remoting/RemoteCatalogService, ready to go. Pretty slick, huh?

OK, so a few things to point out before I move on. We are using AOP under the hood, so what you are creating is very similar to a proxy object, and it uses the same mechanism for method interception. So what does that mean? Well for one thing, adding translation to and from AS objects to CFCs is a matter of adding a type of around advice configured specifically for remoting. Of course this component is provided by ColdSpring, and the RemoteFactoryBean knows how to configure it for you, all you have to do is properly configure a flashUtilityService and give it to the RemoteFactoryBean. Here’s how we set that up:

<bean id="flashMappings" class="coldspring.remoting.flash.flashMappings">
    <constructor-arg name="mappings">
    
    <list>
        <map>
            <entry key="cfcType">
                <value>net.klondike.component.Record</value>
            </entry>
            <entry key="asType">
                <value>RecordVO</value
            </entry>
        </map>
    </list>
    </constructor-arg>
</bean>


<bean id="flashUtilityService" class="coldspring.remoting.flash.flashUtilityService">
    <property name="flashMappings">
        <ref bean="flashMappings"/>
    </property>
</bean>

I’ve defined a ColdSpring flashMappings object with the cfcType and asType to translate between. You provide a list of mappings, each one is defined as a map with a key for the CFC and AS types to translate between. Next I simply define the flashUtilityService and provide the mappings object. So now I just give this service to the RemoteProxyBean defined above. Now the config will look like this, all I have added is the property ‘flashUtilityService’:

<bean id="remoteCatalogService" class="coldspring.aop.framework.RemoteFactoryBean">
    <property name="target">
        <ref bean="catalogService" />
    </property>
    <property name="serviceName">
        <value>RemoteCatalogService</value>
    </property>
    <property name="absolutePath">
        <value>/usr/local/cf7/htdocs/klondike/machii/remoting/</value>
    </property>
    
    <property name="flashUtilityService">
        <ref bean="flashUtilityService" />
    </property>
    <property name="remoteMethodNames">
        <value>get*</value>
    </property>
</bean>

Now my remote service will do all the translation between AS objects and CFCs for me, viola! So what if I want to add a little security to this service, or some logging? As I said before, we are using AOP; RemoteProxyBean actually extends ProxyFactoryBean, and can be configured with any method interceptors or advisors as well. So adding logging and security is pretty much a breeze. I’m not going to go through setting up those advisors, you can read over my first and second AOP tutorials, but here’s how I add them to the remote service:

<bean id="remoteCatalogService" class="coldspring.aop.framework.RemoteFactoryBean">
    <property name="target">
        <ref bean="catalogService" />
    </property>
    <property name="serviceName">
        <value>RemoteCatalogService</value>
    </property>
    <property name="absolutePath">
        <value>/usr/local/cf7/htdocs/klondike/machii/remoting/</value>
    </property>
    <property name="flashUtilityService">
        <ref bean="flashUtilityService" />
    </property>
    <!-- add the logging and security advisors --
    <property name="interceptorNames">
        <list>
        <value>loggingAdvisor</value>
        <value>securityAdvisor</value>
        </list>
    </property>
    <property name="remoteMethodNames">
        <value>get*</value>
    </property>
</bean>

There you go! I added the logging and security advisors in the same way as if I was setting up a normal AOP proxy bean, and that’s it. I now have a pretty sophisticated remote service, with type translation, logging and a security framework all built in, and I didn’t write a speck of code, all I did was rewire existing components from my application. Now that’s cool!

Now all that we need to do is ask ColdSpring to actually create the remote service. There’s a couple of ways you can do this. If you call getBean(‘remoteCatalogService’) on the factory, that will follow the same principles as when using any factory with ColdSpring, and create the service. However, the RemoteFactoryBean has some useful methods for managing remote services, so you may want to retrieve the factory itself from ColdSpring. You can do this by calling getBean(‘&remoteCatalogService’) on the bean factory. This will return an instance of the factory itself and you can then call factory.createRemoteProxy() to create the service, factory.destroyRemoteProxy() to remove it, and factory.isConstructed() to see if the service is ‘alive’. I have some creative uses of the RemoteProxyBean api that I’m looking forward to showing at cf.Objective, so I’ll see you there, and happy remoting!

cf.Objective sessions announced!

2006-02-09T04:11:00.000-08:00

It’s 6:45 in the morning and I just got the cf.Objective session schedule and it looks so good I just have to tell the world immediately! I have to say that I am very impressed with the way this conference is turning out. Jared has put some extremely hard work into this thing, and it’s really paying off. From what I understand he’s been doing pretty much all of the coordinating by himself, he really deserves all the accolades he can get. But let’s get to the conference, shall we, my nose is getting too brown for comfort here! This is going to be a much more advanced leaning conference that other cf conferences that I have been to, that’s for sure, with a definite lean towards enterprise level application engineering. We have Software Engineering, Advanced Enterprise Engineering, and I’m really happy to see, Enterprise Server Tuning as session tracks, and pretty much every session in each track looks great. I particularly like the very timely mashup of Hal Helms speaking about Duck Typing, followed by yours truly speaking about AOP. We should cover a wide range of typing issues there, I have no idea if we will end up on opposite sides of the fence or not! Matt Woodward is doing OOP for nOObz, S Isaac Daeley on SQL Abstraction, Kevin Schmidt on SMS Gateways, it just goes on and on. I just can not imagine missing this conference if you have any interest in advanced coldfusion at all! So get out and register! NOW!

Mixins in ColdSpring? What would you like?

2006-01-12T18:02:00.000-08:00

So a while back I was thinking about the ColdSpring AOP framework, and expanding it to support mixins. I really like the idea of doing something like this declaratively, I think it will be much cleaner and easer to debug when configuration is done from outside of your cfcs. What a surprise to read posts by both Joe and Sean today about ways to implement mixins! Well, I'm definitely going to get this started next week, (I really have to finish something first, there's a _remote_ possibility it will be done tomorrow, hint hint...) so if anyone has any wishes, drop a comment and we'll see what we can get in there. I mean, there's not too much to it, we'll be adding methods and perhaps instance data to cfc declaratively, but there were some comments on both blogs that make me think that I'd like to hear how people see using mixins so we can work that into the implementation. Thanks for the input!

Get On the Bus! Register for cf.Objective!

2006-01-09T11:01:00.000-08:00

Looks like I’ll be speaking at cf.Objective in March, along with some really great cf-gurus, Sean Corfield, Hal Helms, Joe Rinehart, Matt Woodward, Jared R, among others. Personally I’m really excited, it looks like Jared’s definitely trying to get this conference wrapped around some advanced enterprise level sessions. So get signed up!

Sean Corfield Spawns More Interface Debate…

2006-01-09T10:49:00.000-08:00

The debate on whether or not ColdFusion needs interfaces returns, headed up by a really good post by Sean Corfield. There’s some excellent discussion going on in the replies, I’d say this is a definite must read thread. As good as many of the points are, however, I’m not swaying, I want interfaces, and as soon as I get my thoughts together, I’ll show some examples of how they can be used very effectively. One thing I would like to throw in is that interfaces aren’t only about typing and providing a contract for your objects. Interfaces can give your objects sudo-multiple inheritance. Lets say your object extends one base class, but also satisfies the methods for two interfaces, if you have methods in some objects that take arguments of any of those three types, four including the type of the composite object, that object can satisfy any of those type constraints, thus acting as 4 different objects from the point of view of the various methods. If we set the argument types to ‘any’ or ‘WEB-INF.cftags.component’, that method will accept any object, and we void all contractual obligations of our objects, no matter how conceptual they really are in ColdFusion.

Creating ColdFusion’s missing ‘instanceof’ method

2006-01-05T18:32:00.000-08:00

Yesterday I was going back over some ColdSpring code, implementing some new features, and I came across the answer (sort of) to a question I remember being discussed a while back on CVCDev or topica. How do you find out if an object is an instance of a particular cfc or one of it’s subclasses? Unfortunately, ColdFusion doesn’t have the keyword ‘instanceof’ like Java and C#, which I suppose is far more commonly used in a strongly typed language. Why would it be more necessary? Well, for one thing the O’Reilly C# book I have advocates the use of instanceof before casting, alleviating ClassCastExceptions, but that’s another story. Anyway, I have run into a few situations in ColdFusion where I really need this functionality. So how do we do this in CF? Well, when I looked at what I had written a few months ago, although it works ok, the comment below it, ‘shouldn’t I be looking in the ‘extends’ key only?’, basically pointed out that it was a shotty implementation at best (btw, I looked back over the history of the file, and the original comment was ‘this sucks, I need to do this better later!’), so I asked Sean what he thought about it. Here’s something along the line of the original code I sent him, the main problem here being that by using StructFind() I am searching every key in every nested struct:

Sean immediately pointed out that that was ok, but slow. Maybe I should search recursively through the extends keys of the metadata. So here’s what I ended up with, which seems a heck of a lot tighter to me. I shied away from the recursive method call, because that seemed it would be putting a little extra overhead on the search, but this implementation seams nice to me, thank for the input Sean!

Fresh for 2006… ModelGlue for Java!

2006-01-03T10:47:00.000-08:00

About a month ago I went down to the DC area to visit with Sean Corfield, Joe Rinehart, Doug Hughes, Scott Boyziod, and a few others, and for some reason Doug and I were talking about his port of ModelGlue for .Net. I don’t know why, maybe for pure masochism, I mentioned that maybe I would be interested in porting ModelGlue to Java. Well Joe though it was a good idea as well, so I decided to give it a go! Over the past month a few people have asked me why I would want to do such a crazy thing, and I do have some reasons! Most importantly, I know a lot of cfers are starting to think about getting into J2EE development, and I know from personal experience, that the initial learning curve, not so much of the language itself, but really of the architecture of J2EE, can stop people in their tracks. Maybe a familiar framework would be a bit of a helping hand? I think so. I’ve done a few J2EE apps and one of the things that I always seem to find myself saying is, ‘man I really like working with mach-ii and modelglue much better that any of these java frameworks’. Struts is too big and too messy for me, SpringMVC is actually pretty nice, but still kind of heavy. For me, I think ModelGlue sits about right for an MVC framework, since it is so lightweight. So I’d like to announce that an early alpha pre-release is not available from svn://clearsoftware.net/clearsoftware.net/ModelGlueJava.

A few notes about this early release:

Spring support is built into the framework, but by doing so, it is currently dependent on the spring distribution. Spring.jar is included in the lib folder of the distribution, along with other dependencies such as commons.beanUtils. An example of defining your controllers in a Spring config file can be seen in the Klondike Records sample app.

I have not implemented asynchronous messaging or session state container support yet, but everything from the current BER of ModelGlue should (maybe) be implemented.

I did make one possibly major, but really semantic change, that I just thought fit better into java. The viewState that you would normally access in views is called eventModel, and is of type EventModel, which extends HashMap. So add(Object key, Object value) and get(Object key) as well as other HashMap methods are available if getValue(String key [, Object defaultValue]) ) is not to your liking. I just really feel strongly that as a user we are dealing with a model object that is tied to the event when setting/accessing values in our controllers and our views. The names have changed to protect the innocent, but nothing more!

Final notes, I’m not done at all! I’m hoping an early preview will gain some interest, and maybe some input and assistance from other java/cfers out there, so have fun, and of course, I’ll be changing things for a while!

Joe on Inversion of Control!

2005-12-21T14:01:00.000-08:00

Last night I got into a nice long discussion on the DAL.net coldfusion channel with blanketgirl, no idea who she is, which ended up cornering me into trying to explain why ColdSpring is actually a good thing, not just a whole bunch of xml based hubbub. Unfortunately, since I was relaxing and having a few beers, my defenses didn't go too far past the basics of dependency injection and why I think it so usefull, shots easily deflected by the xml hating blanketgirl! What a surprise to read this excellent post on Inversion of Control by Joe Reinhart today!. Joe puts out a very solid example on using mock implementations in development, but being able to make deployment changes in the ColdSpring config file, not in code. Hey man, where were you last night when I needed you! Kudos to a very well written post, and since Joe mentions that he will be writing about AOP soon, I'm very much looking forward to some great articles. Thanks again, and blanketgirl, go read up!

Defending the Bean

2005-12-19T08:15:00.000-08:00

Over the last week there’s been some really interesting discussion about the idea of an ‘Anemic Domain Model’ for some reason including rethinking the usage of DAOs. I find it a pretty strange concern, if you want me to be honest. I’m not sure I follow the logic of reorganizing tiers of your domain model just to satisfy this notion that every object MUST have logic in them. Here’s some background, most of this discussion refers to this thread on TheServerSide which raises concern over having thin domain objects that are passed into DAOs for persistence instead of knowing how to persist themselves (ActiveRecord pattern, btw). The funny thing is the very first reply sums everything up pretty well by bringing up the analogy of a Cake (your anemic bean), an Oven (your persistence mechanism) and a Baker (which he says is the controller, I’ll get to that). In his scenario he asks the question, does a cake know how to bake itself? Of course not. I have a slightly different take on this example, though.

You have a bakery, it’s a service, which provides cakes, as well as cookies and bread and what not. Components that make up the bakery, like the refrigerator, the oven, the display case, the baker, are each part of different tiers that, when composed together into the bakery, provide services to return cakes, cookies, bread, etc. Lets look at that oven/persistence tier. What exactly is wrong with putting persistence code into it’s own tier now? Doesn’t that assist in making clean, cohesive components? If I put that logic into the Cake object, isn’t that muddying up the logic of the cake a bit? Personally I find the DAO approach to fit nicely into an organized persistence tier off my applications. And, of course, ColdSpring will assist in building that bakery. Just as a side note, in the TSS thread the consensus was quickly reached that the DAO example was a pretty bad choice. So what was the issue again? Oh yeah the thin business objects.

This is an argument that has been going on in the Java world for a while now. It’s against using transfer objects, because they don’t actually have any real business logic in them, so they’re not a real objects. I guess it could be said that this is contrary to the basic ideas of object oriented design, ok I guess Martin Fowler can say that. Rod Johnson, the creator of Spring, also warns against writing objects that only contain methods to expose their data, as they are not actual objects. But lets look at this. This is a Java issue. Java has no lightweight typed objects. C# solves this by providing an excellent Struct implementation which is really a lightweight typed class. So when you ask for the ‘name’ you get a String back. Quite different from Java’s alternative, various types of Maps, which all return Objects back, so casting is necessary. For many purposes, using a bean is a better alternative to a map, because getters return data in the correct type (this is addressed with generics in java 5). But wait a second. ColdFusion. Don’t we have a Struct? Of course we do. Any we are dynamically typed, so the casting issues are not a problem. So if transfer objects are such a problem, why not use Structs, right?

But wait. I don’t think we’ve really looked at the issues here. There’s more to consider. Typing IS an issue. We need to validate types when putting data INTO transfer objects, we want numbers to be numbers, not strings, just for a simple example of why, consider this. We pass a struct into a gateway object to retrieve all users of typeID=6, our where clause looks like this: WHERE user.typeID = #myStruct.type#. But some wily hacker comes along and figures out how to set that value to ‘truncate table user’. Whoa, hold on! That’s like uh, SUPER BAD! Certainly having a numeric type enforced on that data could have really helped here (any yeah I know, queryparam could help, but that’s not my point). I could have also built a validate method in either the TO or validator object which could have been used by some service object before even attempting to send the TO to the DAO. The point is that even though beans / TOs have little logic in them, their use is a part of a bigger picture, which makes up business logic. I have a novel idea that beans and transfer objects are actually part of architectures which represent logic by design. Isn’t that a huge part of OOP anyway? Complex logic is often represented by the interactions of the objects that make up our domain model. Some of those objects are going to make up our Persistence tier. Some of them are going to make up our Service tier. Some of them are going to be Domain Objects and represent our primary business (we sell books, so we have book objects). And some of those objects may very well be lightweight objects, but they assist in clear separation of our logic, they assist in typing and data validation, they may model forms from our view tier, etc, etc. Are they second class citizens on our domain, no way! Embrace the Bean!

Reinventing the wheel is BAD!

2005-12-08T11:23:00.000-08:00

I know you’ve probably been told that before, and it’s one thing I’ve told myself over and over again, but sometimes I just forget. I’m working on a soon to be explained, but I’ll keep quite for now, little side project in Java which requires creating beans and setting properties (hint). As I got down into the setProperty methods, I realized the rabbit hole is a lot deeper than I thought. The problem is, I will have a property name and a value that I want to find a method for in some given object. So I can look for methods with reflection, but a lot of issues arise. I have to look for a method that accepts not only the type of value I have, but also any classes it extends, the same goes for interfaces. Also, the bean may accept a primitive type, such as int, but for all sorts of reasons, you may have to wrap that value as an Integer object, which means I need to try to un-box those types (that’s what c# calls it, I can’t remember the java term) as well. After more than an hour, and after all sorts of methods, (setProperty is now becoming a chain of 4 or 5 methods and I’m not done!) I realized I better do some googling to see how this is done in say, Struts. I ended up looking into some apache commons code, initially reading it (dumb), when it struck me. What the hell am I doing? This code is written, and open source! Duh! So I scrapped my code and replaced it with one line of code using commons.beanUtils.

Moral? Reinventing the wheel is a waste of time! There are lots of GREAT open source solutions to many common problems, the apache commons project is just one of them, specific to Java programming issues. The great thing is, other than the fact that the code is already written, you or I are just one person, dealing with the issues of entire systems. These tools are written by groups of very skilled programmers, they are singularly focused to provide highly tested, well written solutions, which are probably going to be better designed than what you or I are trying to come up with. I spent 2 hours doing something that really only had to take 5 minutes! This is one of the core mantras of the book Better, Faster, Lighter Java, which I guess I forgot for a second.

Excellent ColdSpring posts

2005-11-28T06:11:00.000-08:00

Sometimes the people who write the frameworks may not be the best at explaining them. Too intimate with inner workings, or perhaps too proud and wanting to divulge every - not actually fascinating - bit of alchemy involved. Lucky for me, there's some excellent blogs out there writing about ColdSpring. Scott Barnes posted Coldfusion on Cruise Control today, and yesterday Matt Woodward posted ColdSpring: Better Model Management, both great articles and should be helpful to developers just getting their feet wet with ColdSpring. Thanks guys!

ColdSpring 0.5.0 Alpha Released!

2005-11-17T16:50:00.000-08:00

We've just posted ColdSpring 0.5.0 Alpha over at www.coldspringframework.org containing numerous bug fixes and enhancements. The AOP framework should be significantly faster, and also contains a revised AfterThrowing Advice and MethodInterceptor. Sean Corfield's Autowire controller for ModelGlue is included along with a revised Mach-ii plugin which had autowire capabilities, as well as new Remoting helper classes and Hierarchical BeanFactory and Application Context support contributed by Kurt Wiersma

ColdSpring AOP Tutorial – Part Two, Around Advice

2005-11-15T10:34:00.000-08:00

First off, sorry for the long delay in the AOP tutorials. I’ve been working pretty hard on the aop framework for a new release, and I don’t want to blog about features that are not yet available. Since we are going to do a 0.5 release this week, though, it’s time to get back on track. One thing I need to point out is that you will need to get the latest BER from CVS to try these examples, unless you already have the 0.5 release. Ok, so lets get back to where we left off. We previously talked about writing Before Advice to provide logging services to CatalogDAO. Although I didn’t discuss After Advice, we could have accomplished the same thing, with the added ability to log information about the return values from the method calls in our loggingAdvice by extending coldspring.aop. AfterReturningAdvice and putting the logging code in the method ‘afterReturning()’ instead of ‘before()’. Lets take a quick look at what that advice object would look like:

A few things to note here, we have to check to see if ‘returnVal’ actually exists in arguments before using it, because if the method you are advising does not return a value, ‘returnVal’ will not exist. Also, and this differs from the early alpha release, it is not necessary to return ‘returnVal’ if it exists. This value is available for you to inspect only. If you need to alter the result of method invocation, you should be working with Around Advice. In order to configure this Advice, we would take the same steps as we did with the Before Advice, configure the NamedMethodPointcutAdvisor with this Advice, and configure the ProxyFactoryBean with the CatalogDao as the target.

So now that I have covered the more simple types of Advice, let’s look at the more powerful Around Advice, called MethodInterceptor. First off, let me explain some of the motivation behind the naming convention. There is an organization called the Aopalliance that has provided standard interfaces to method interception for the development of aop frameworks. The idea being that as long as developers adhere to these interfaces, your code will be portable across different aop implementations. That sounds like a good idea to me, since who knows if someone is going to come along and write a much better aop framework that I have done. So that being said, MethodInterceptor is a type of Around Advice, meaning that it allows you to place code before and after the method call, and gives you complete control of actually calling the method. So let’s see how this works in practice, and while we’re at it I’ll cover some of the api available in the framework. This time I’m going to create an Advice to cache cfcs returned from the dao’s fetch() method, looking first to see if they exist there, and also update the cache in the save() method. This implementation is pretty simplistic and should not be viewed as a real world example, but hopefully it will get your mind going. First lets review the CatalogDAO cfc so know what methods we are going to be advising.

<cfcomponent name="CatalogDAO" output="false">

  <cffunction name="init" access="public" returntype="Any" output="false">
    <cfreturn this />
  </cffunction>

  <cffunction name="setDataSource" returntype="void" access="public" output="false" hint="Dependency: datasource name">
    <cfargument name="dsn" type="string" required="true" />
    <cfset variables.m_dsn = arguments.dsn />
  </cffunction>

  <cffunction name="fetch" returntype=" net.klondike.component.Record" access="public" output="false">
    <cfargument name="recordID" type="numeric" required="true" />
    <cfset var record = CreateObject('component','net.klondike.component.Record').init() />
    <cfset var qrySelect = 0 />

    <cfquery name="qrySelect" maxrows="1" datasource="#variables.m_dsn#">
    SELECT QUERY …
    </cfquery>

    <cfif qrySelect.RecordCount>
      <cfset record.setRecordID(qrySelect.recordID) />
      <cfset record.setArtistID(qrySelect.artistID) />
      <cfset record.setGenreID(qrySelect.genreID) />
      <cfset record.setTitle(qrySelect.title) />
      <cfset record.setReleaseDate(qrySelect.releaseDate) />
      <cfset record.setImage(qrySelect.image) />
      <cfset record.setPrice(qrySelect.price) />
      <cfset record.setFeatured(qrySelect.featured) />
    </cfif>
    <cfreturn record />
  </cffunction>

  <cffunction name="create" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryInsert = 0 />

    <cfquery name="qryInsert" datasource="#variables.m_dsn#">
    INSERT QUERY …
    </cfquery>
  </cffunction>

  <cffunction name="update" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryUpdate = 0 />

    <cfquery name="qryUpdate" datasource="#variables.m_dsn#">
    UPDATE QUERY …
    </cfquery>
  </cffunction>

</cfcomponent>

Obviously a little SQL has been removed, and I’ve also included a change in the fetch() method. We are now going to create a Record cfc from the data in the query and return that instead of a query object, so we can cache it. OK, so lets look at the around advice.

So let’s examine what’s going on here. First we extend coldspring.aop.MethodInterceptor and overwrite invokeMethod() which receives an argument of type coldspring.aop.MethodInvocation. MethodInvocation will take care of moving through the chain of any Advice defined and then call the proxied method, by calling its proceed() method. The other public methods for MethodInvocation are getArguments() which returns the arguments you sent to the proxied method, getMethod() which returns a Method object which represents the actual method call, and getTarget() which returns the proxied object itself. From the Method cfc returned from getMethod(), getMethodName() is available as well, so you can see you pretty much have full access to the method call. In invokeMethod() above, the first thing I do is set some local variables to getArguments() and getMethod().getMethodName(), retrieving the argument collection and the name of the method. If the method name is ‘save’, I look in the local cache to see if a Record cfc exists that hasn’t expired, and if it does, I return that object instead of proceeding with the method call. If the Record instance doesn’t exist in the cache I store the result of calling proceed() in the cache. The ‘fetch’ method similarly will store the result of proceed(), and all other methods simply call proceed() without performing any additional work. There’s a very important point to take care to understand here. When using around advice, you are responsible for calling proceed() to get the method to execute and you are also responsible for returning the result of that call if necessary. This completely differs from using Before or After advice, where neither the method call or the return are your responsibility. This obviously makes Around Advice far more powerful, but you may want to think twice before using it if you don’t need to alter the method call itself. One other thing to take note of, if this particular Advice is not the last Around Advice configured, than any other Around Advice will NOT execute when I retrieve the Record cfc from the cache, because of the fact that I am not calling proceed(). This is another pitfall to be very weary of when designing apps using this technology!

So lets move on to the configuration. This time I am going simplify things a bit by skipping the setup of the Advisor all together. If you don’t care about matching the methods in a target, because your intension is to match all methods as you would with the ‘*’ pattern, you can just reference the Advice directly in the interceptorNames list for the ProxyFactoryBean. This will internally create a DefaultPointcutAdvisor for you, which will match all methods in the target. The resulting configuration file will look like the following.

<bean id="simpleCachingAdvice"
  class="net.klondike.aspects.simpleCachingAdvice" />


<bean id="catalogDAOTarget"
  class="net.klondike.component.catalogDAO">
  <property name="dsn">
    <value>klondike</value>
  </property>
</bean>

<bean id="catalogDAO"
  class="coldspring.aop.framework.ProxyFactoryBean">
  <property name="target">
    <ref bean="catalogDAOTarget" />
  </property>
  <property name="interceptorNames">
    <list>
      <value>simpleCachingAdvice</value>
     </list>
  </property>
</bean>

You can see that this is a little more convenient, but there will be a bit of overhead in the fact that the all method calls will be processed through the interceptor instead of just the methods that actually use the cache. You may also have noticed that I also added a method to my advice that is not directly used by the aop framework, flushCache(). Just because an advice object is used by the aop framework doesn’t mean it’s not a full fledged business object! You can still retrieve the simpleCachingAdvice from the coldspring bean factory with a call to bf.getBean(“simpleCachingAdvice”) and call flushCache() in some other object in your application. This gives you an enormous amount of flexibility and power. Think about counting method calls. Have you ever put a tracking system in your apps to keep track how many users are in the system and the last thing they did? How many places in your app would that code exist, more importantly how easy would it be to turn off that system? Definitely a candidate for aop! Well I hope that I’ve sparked some more interest and brought some more of the details to light. Look for the next installment where I will cover building a suite of throws advice with the new After Throwing object, and I’ll try not to let so much time go by this time!

Joe Rinehart introduces Arf!

2005-10-31T19:37:00.000-08:00

With all of the hubbub about Ruby on Rails running around, it was only a matter of time until some smart person came along and wrote an implementation of Active Record for codfusion. Well it looks like that smart person is Joe Rinehart! Congratulations Joe, I’ve though a bit about active record myself and I’m sure that it was a lot of work. I’m really excited about messing around with it, and I think it’s another great step for the language in general. These are exciting times for coldfusion!

ColdSpring has a new home!

2005-10-28T17:32:00.000-07:00

Dave has just announced the opening of www.coldspringframework.org, where you can get the latest stable release as well as cvs access to bleeding edge versions. You'll also find documentation as well as api docs, forums and a listserve. Dave really put a lot of hard work into the site, and I did a little design work as well. It looks great and I think it will be a great resource, so check it out!

Announcing Team Fusion!

2005-10-23T18:37:00.000-07:00

I’m not sure how people get into these super-hero programming alliances, so I started my own, Team Fusion! We’re very serious and action oriented, so we get an exclamation point as well as a star. Ok, I just wanted a cool logo for my coldfusion friends’ links and it sounded funny to me, so I killed an hour making it. But if anybody thinks I should add someone to the all powerful Team Fusion!, let me know!

A few picks...

2005-10-16T08:09:00.000-07:00

I just added a few picks from the frameworks conference and the following friday night to my flickr site. Dave and I split kind of early and went to my friend Erik's house in baltimore. Erik has somehow become the caretaker of a small circus train once owned by the famous side show attraction and baltimore native Johnny Eck. We had an amazing time drinking lots of beer, driving the train around his backyard, and getting a significant and well earned lecturing by Erik's wife. Sorry Charlotte!

Model Glue is Good!

2005-10-13T19:31:00.000-07:00

Ok, you already know that, but I've never worked with model glue before. I've been a mach-ii guy for a while and I like it. But now that coldspring is said to be super easy to integrate with mg, I figured, I better take a look. So here's a quick rundown of the day. 10:00, I slept late, OK? My kids stayed at their grandparents last night, it's the first day I've slept passed 7:00 in years! Anyway, at 10:00 I got model glue from svn, went straight for the ber! I figured I better clean up my dev machine at this point because I had 3 versions of coldspring and 2 versions of the record store example app on there, so that took a little while. I changed the layout of the model components a little and shifted around my root folder so both controller apps could share a config folder, as well as the coldspring config file.

After initial set up, I decided to read the quickstart guide, OK skimmed it, and figured I'd jump in and see if things would just work. I copied the 2 listeners in to the controllers.mg folder, replaced all the event.getArgs() with event.setValue() and put return values back in the event instead of returning them. I really like this part. I have had numerous discussions with mach-ii developers about putting data in the event in listeners, instead of all the request scope stuff. I have apps that do this exclusively, so this fits perfectly to me. I hit the views next, this was basically nothing. I just switched my event.getArg() to viewState.getValue(), which I do first thing anyway to get local references, so that was simple. I did all this before creating the xml, since I figured that's where the differences would lie.

Working with the xml file was really pretty easy, my only big problem was I read the quickstart guide too fast and didn't put my message tags in a broadcast block, so when I fired up the app, I got my layout view with nothing. Then I figured out the proper way to use the ViewCollection.getView() method and got my nice layout page with my error template. However, looking at some debugging I did see that my model components were completely wired up through coldspring no problem! After a little more kludging and some teasing in the coldspring irc channel I think I got into the swing of things pretty well. Since mg has no filters, that means more control logic in the controller, so it's a little heftier that the corresponding listener. Is that a bad thing? I don't think so. Why do I need xml to tie all that logic together anyway? A few things here and there kind of tripped me up, but after I felt a little more comfortable, I stopped trying to make mg fit the app that I already had written, and worked on it as a mg app instead. So after all that, I had a completely functioning app at 5, inheriting all the model goodness from the mach-ii app, logging, security and caching.

Overall impressions? I like it, as a matter of fact I really like it. One of the things that's great about coldspring is it's very lightweight, especially if you're using Sean's autowire controller for mg or our autowiring plugin for mach-ii (which will be in the next release). Coldspring just does its work and gets out of your way. Model glue seems to follow right along with that mantra, it's nice and light. Filters and plugins are very powerful, but maybe we don't need them so much. Maybe we don't need to rely on them so much, to be more precise. You need to concentrate on business logic, and model glue gets right out of your way, and lets you get to it!

ColdSpring 0.2.1 with AOP Released!

2005-10-09T20:38:00.000-07:00

Emerging from the depths of vaporware the coldspring.aop packages have been released along with a point release of ColdSpring! Dave has also included a Model Glue adapter, which you can read about on his blog here.

Download ColdSpring 0.2.1

ColdSpring AOP Tutorial – Part One

2005-10-08T20:15:00.000-07:00

Since I have already given an overview of ColdSpring’s AOP concepts, I’m going to just dive right into things. For part one of the developing with ColdSpring AOP, I’ll show how you can use a simple form of Advice called Before Advice to provide logging services to a model component. These examples are from the Klondike Records application that I showed at the frameworks conference last week, which we will also be releasing as an example application. I’ll show you how to define an Advice cfc, which will extends coldspring.aop.BeforeAdvice, how to define Pointcuts via Advisors in a standard ColdSpring config file, and how to use coldspring.aop.ProxyFactoryBean to wrap the Advice around methods of a target object by creating a Proxy object, containing the target. Think about the proxy object like an egg. The object you want to apply logging to would be the yoke and the Advice that provides the logging functionality is the egg white surrounding it. When the proxy factory creates this egg, and this is the great part, everything in you application thinks that it’s the same object that’s in the yoke! OK, so so let’s get right into it. First we’ll define a model component, which will be called CatalogDAO.cfc which we’ll then add logging services to.

<cfcomponent name="CatalogDAO" output="false">

  <cffunction name="init" access="public" returntype="Any" output="false">
    <cfreturn this />
  </cffunction>

  
  <cffunction name="setDataSource" returntype="void" access="public" output="false" hint="Dependency: datasource name">
    <cfargument name="dsn" type="string" required="rue"/>
    <cfset variables.m_dsn = arguments.dsn />
  </cffunction>

  
  <cffunction name="fetch" returntype="query" access="public" output="false">
    <cfargument name="recordID" type="numeric" required="true" />
    <cfquery name="qrySelect" maxrows="1" datasource="#variables.m_dsn#">
    SELECT QUERY …
    </cfquery>
    <cfreturn qrySelect />
  </cffunction>

  
  <cffunction name="create" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryInsert = 0 />
    <cfquery name="qryInsert" datasource="#variables.m_dsn#">
    INSERT QUERY …
    </cfquery>
  </cffunction>

  
  <cffunction name="update" returntype="void" access="public" output="false">
    <cfargument name="record" type="net.klondike.component.Record" required="true" />
    <cfset var qryUpdate = 0 />
    <cfquery name="qryUpdate" datasource="#variables.m_dsn#">
    UPDATE QUERY …
    </cfquery>
  </cffunction>
</cfcomponent>

Obviously we’re skipping some details, but the point is that this is just a standard model component; we don’t extend anything or put any special code here. The component should be completely usable with or without AOP. In my example app you will see that this dao is used as part of a service component, which is used by the catalogListener in the mach-ii app. The nice thing about using AOP to provide logging is that neither the dao nor the service component that uses it will have any code in them pertaining to logging. They are only concentrated on fetching and storing records, cohesion. I like to use log4j, so I’ll create a LoggingService cfc to handle the configuration details and provide a common api to my Aspects. Also, if I want to switch this out to use cflog or another implementation, I can do that in one place. So here’s the LoggingService cfc, but I’ll skip showing how to actually configure log4j, since I have already shown that in an earlier post. This service basically just retrieves the logger and wraps its info() method.

Ok, now onto the AOP part. I will first create a Before Advice to retrieve information about the current method being invoked and send it off as the message argument to the logging service’s info() method. Here’s the loggingBeforeAdvice cfc.

This probably looks more complicated that it really is, so I’ll walk through it. First off we extend coldspring.aop.BeforeAdvice, which provides typing for the aop framework, and the ‘before’ method which you will overwrite. Next we have a setter and a getter which ColdSpring will use to inject the LoggingService, and the AOP framework will use to clone the Advice. The heart of this cfc, however, is the before() method, which gets passed a Method object, responsible for handling the actual method call, the argument collection passed to the method, and the target object which receives the method call. You can see that you have an amazing amount of power at this point. But all I’m going to do here is get the name of the target object through metadata, the name of the method from the Method object, and I’ll loop through the arguments to find simple values that I can print as strings. From this I make a string to pass to my loggingService that will look something like this: ‘[net.klondike.component.catalogGateway] getGenres() called!’. One important thing to note here is that Before Advice can alter the arguments going into the method at this point, but is not responsible for actually executing the method, even though it does have access to it. There is another type of Advice that should be used if you want control over method execution, called Around Advice, but I will delay that discussion until part two. Here’s where the advice of ‘be really careful’ comes in. No other object in you application has any idea of what is going on at this point, so you can really cause havoc, so be careful!

Ok, so now we have a DAO that we want to apply logging to, a simple loggingService, and a Before Advice to apply the logging service with. Now this may seem like a lot of work to add logging to a method, and that’s true. But this Advice can be applied to ALL you model components without writing any more code, logging method calls across your entire application. All that’s left is configuring these components. As I wrote in my earlier post, this is a matter of identifying Join Points, methods that you want to log in objects, which is done through Pointcuts, with an Advisor. An Advisor is basically a collection of methods and advice to apply to them. OK, so here’s the ColdSpring config file that will tie all this together.

<beans>

  <!—define the logging service -->
  <bean id="loggingService"
class="net.klondike.component.LoggingService" />

  
  <bean id="loggingBeforeAdvice"
class="net.klondike.aspects.loggingBeforeAdvice">
    <property name="loggingService">
      <ref bean="loggingService" />
    </property>
  </bean>

  <!—now define a NamedMethodPointcutAdvisor, set the advice property to the bean above, and set its mappedNames property to ‘*’ which will create a pointcut to match all methods excluding any init method -->
  <bean id="loggingAdvisor"
class="coldspring.aop.support.NamedMethodPointcutAdvisor">
    <property name="advice">
      <ref bean="loggingBeforeAdvice" />
    </property>
    <property name="mappedNames">
      <value>*</value>
    </property>
  </bean>

  
  <bean id="catalogDaoTarget"
class="net.klondike.component.catalogDAO">
    <property name="dsn">
      <value>klondike</value>
    </property>
  </bean>

  
  <bean id="catalogDAO"
class="coldspring.aop.framework.ProxyFactoryBean">
    <property name="target">
      <ref bean="catalogDaoTarget" />
    </property>
    <property name="interceptorNames">
      <list>
        <value>loggingAdvisor</value>
      </list>
    </property>
  </bean>

  
  <bean id="catalogService"
class="net.klondike.component.CatalogService">
    <property name="catalogDAO">
      <ref bean="catalogDAO" />
    </property>
  </bean>

</beans>

That’s it for the configuration. When you ask the ColdSpring bean factory for your catalogService, ColdSpring will create the ProxyFactoryBean and ask it to return a proxy object. The ProxyFactoryBean will in turn get a reference to the target object, the real DAO object, get the Advisor which contains the Aspect we created, causing the loggingService to be created, and will finally generate an entirely new cfc, which contains the target object, the proxy for the catalogDAO. This proxy object will be the same type as the target object and will contain all the same methods as the target, except that it will now flow every method through an instance of the loggingBeforeAdvice. If I want to add the same advice say to a gatewayObject, all I have to do is create another target object, and another ProxyFactoryBean and give it the same Advisor. If this doesn’t seem powerful enough for you, you can also create a new Advice, say a securityAdvice, and create a new Advisor, matching only the ‘save’ method, and give this to the ProxyBeanFactory we defined above. That would make that bean definition look something like this:

<bean id="catalogDAO"
class="coldspring.aop.framework.ProxyFactoryBean">
  <property name="target">
    <ref bean="catalogDaoTarget" />
  </property>
  <property name="interceptorNames">
    <list>
      <value>loggingAdvisor</value>
      <value>securityAdvisor</value>
    </list>
  </property>
</bean>

Adding the securityAdvisor after the loggingAdvisor causes it to be chained after the loggingAdvice, so if that Advice does something like throw an ‘InvalidCredentials’ error, the loggingAdvice will get a chance to write to the log before the method execution stops. So that’s just a small piece of the framework, the least powerful type of Advice we have available. After Advice is very similar to Before Advice, except that it occurs after method execution, giving you access to the return variable from the method as well as argument collection that was passed into the method. Wow, so that’s a pretty big blog post! I hope I’ve wet your appetite, and stay tuned because a super-prealpha-ubermethodology-oops-sorry-release is just around the corner!

Whoa, there’s a lot of code in there!

2005-10-07T18:48:00.000-07:00

I just popped over to the fisheye site that Dave and I use to track development and there’s a lot of code going into that there cvs! From mid September there have been over 10K lines added! We’re closing in on 20K in the ColdSpring repository! Now granted, there’s a whole bunch of example apps, tests apps, and I think maybe Dave added the Macromedia pet store app, but the point is ColdSpring is very active right now. Expect big releases very, very soon. I’m doing my best to release the AOP framework this weekend, so stay tuned! I swear we’re not sleeping…

Bye the way, incase you haven’t been told this before, Fisheye’s the bomb! If you use cvs or subversion, you have to take a look at Fisheye. Of course if you don’t use some type of source control, um, I have no idea how you are managing your software development, you shouldn’t be doing that. Go get cvs. Right now!

Introduction to ColdSpring AOP

2005-09-27T17:33:00.000-07:00

Aspect Oriented Programming is a fairly new programming model that assists in handling far reaching services, like logging, security, transactions and object caching, in your model. Services like these are beginning to be referred to as ‘crosscutting concerns’, because they are applied broadly across your application. In order to add a service such as logging to an application, you typically find yourself applying very similar code all throughout your model, which when scrutinized, probably has nothing to do with the actual functionality of your components. AOP allows you to insulate these types of crosscutting concerns from the rest of you application, and apply them broadly based on certain policies that you as the developer define.

Using AOP is basically a process of looking at the types of concerns in your application and then breaking them apart into primary concerns, like your managing your shopping cart or navigating through and administering your product catalog, your application’s primary business logic, and crosscutting, generalized concerns, such as logging and security. These crosscutting concerns become what are known as ‘aspects’, and with AOP can be written singularly focused on the issues they solve, becoming more portable and reusable. These aspects are then applied to your model according to policies that you define, through a process known as ‘weaving’, which is performed by the AOP framework.

Defining policies is a matter of identifying ‘join points’ in your model, specific areas where you would like to apply the ‘advice’ of your aspects, meaning the specific action that you would like to take place at a certain time in your application. Join points are created using ‘pointcuts’ which are defined with wildcards or regular expressions to identify methods in your objects. Don’t get too worried about the terminology here; the primary concept is that you already have objects with methods in them that you want to add functionality to. You do this through advice. There are three types of advice available in ColdSpring AOP, before, after, and around advice. Before advice is run before the join point will be performed; after advice will be run after the join point. Around advice is like a combination of both. Around advice is actually quite powerful because it is given full control of the execution of the join point and it has the ability to advise errors through try/catch blocks.
The final concepts to understand in AOP are ‘target’ and ‘proxy’ objects. The target object is object in your model that you want to apply your aspects to. Through the process of weaving, the AOP framework will use the policies you defined via pointcuts to build a new proxy object containing the configured advice, which, and here’s the most important part, appears to be one in the same as the target object to the rest of your application. Now I know a lot of this is sounding confusing and a bit difficult, but it’s important to understand that most of the work is actually done for you. You will primary concern yourself with creating the advice objects themselves. Pointcuts are defined through configuration and ColdSpring AOP handles the rest. In the context of ColdSpring, the configuration is done through an xml file, and the proxy object can be swapped out for the target object with minimal effort.

I’ll post some actual examples after I get a chance to run through them at the conference and get some feedback. Hopefully I’ll get a chance to meet a few people who just may have read some of this there!

ColdSpring, AOP and the Fusebox/Frameworks Conference

2005-09-26T08:21:00.000-07:00

This weekend was one of those crazy weekends that your eyes and wrists hurt and the end of. On top of the kids waking up at all hours so I'm not even getting any sleep, I wrote just a ridiculous amount of code, and now I'm just staring at the work I'm supposed to be doing for my day job like it's in Russian or something. But it was super worth it, because I've got some big news for everyone. First off, for a while now I've been using Dave Ross's ColdSpring CFC container in a big project I'm working on, which kind of lead me to work on ColdSpring. A lot of work was done this weekend merging code with the current version, and that was honestly an exiting experience. I've never before worked with another developer who I see completely eye to eye with, it made me think a bit about pair programming / xp, if it actually is useful. Anybody who has any experience it, please share your experiences, I'd love to hear about it. Anyway, working on ColdSpring kind of lead me into doing a whole lot of work another big side project.

While talking with Dave about the types of things that can be brought into ColdSpring, I started thinking heavily about how the aop framework is used in Spring for Java, and the type of stuff we could build into ColdSpring if we had an aop (Aspect Oriented Programming) layer. So after a hell of a lot of thinking and completely unintelligible chicken scratch notes left around the house, driving my wife nuts when I want to know what happened to the menu with all the little boxes drawn on the back of it, I am very pleased to tell you that I have a functional aop framework to be released in the very near future, hopefully at the Frameworks Conference. I'm not going to go into great detail about what aop is and how it's used right now, I have some real tutorials coming. But I will be going to the Fusebox/Frameworks conference with Dave, where I guess we'll make the official announcement. I have some great examples that I've been bustin my butt to put together, maybe I should have started an example app before this past saturday? I'm looking forward to showing these at a BOF session at the conference, so look for Dave and me there!

Using log4j in ColdFusion

2005-09-21T06:28:00.000-07:00

I went to an interview last Thursday and in the course of it the lead developer and I (my job had apparently been filled!) got into a two hour discussion about caching cfcs with oscache, working with coldspring, aop, and using log4j in coldfusion. Although the interview part didn’t lead to much, I did leave thinking about a lot of cool things, especially pressing being incorporating log4j into a side project that I’m getting pretty heavily involved in. I’ve worked with log4j in java, and it’s super simple, very fast, easy to configure, and I’ve been thinking of using it in cf, but basically haven’t tried. Although I think cflog is just a wrapper around log4j anyway, by using it directly you gain the benefit of setting the max size of the log file created, along with configuration of backup files, the level of logging to output (debug, info, warn, error, fatal), and formatting of the messages. Also, most importantly, it’s really easy to turn on and off, and since log4j is built to be extremely fast the cost of log statements in your code is marginal. So if I’ve peeked you interest, here’s a little rundown of how to get log4j running, with some extra links at the end of the post, including a link to an excellent tutorial on ColdFusion Developer’s Journal, which to be honest, much of this is a paraphrasing anyhow. So on to the code…

The first thing to know is ColdFusion comes with an older version of log4j which uses the now depreciated concept of categories, now known as loggers, but for simplicity’s sake, these are the same thing. An instance of one of these represents a logging space which you are free to name and configure at will. It’s advisable to use package naming conventions with loggers, sorry categories, as this is the norm in java. Also worth noting is that loggers are hierarchical, meaning that a logger named ‘myco.foo’ inherits configuration properties from the logger ‘myco’, if it exists. You perform logging through one of the printing methods debug, info, warn, error, fatal. These are directly related to the standard logging levels DEBUG < INFO < WARN < ERROR < FATAL, meaning the level is ascending. A logging method is considered enabled if it is equal to or grater that the current logging level. So if the logging level is set to WARN, myLogger.error(‘Uh oh, big problem occurred’), will output to your log file, but myLogger.info(‘ran method x()’) will not. The last 2 components to logging are patterns, which I’m going to completely skip, and just give you the logging pattern that you’re pretty much gonna use anyway, and appenders, which you output your logging to. Appenders can be a console, file, a socket server, JMS, NT Event Log, and the Unix System Log, you can start to see the incredible flexibility here. All that’s left is to create a config file and start logging!

I like to use a properties file, the format I mentioned when discussing classloaders, but you can also use an xml file. Here’s a sample properties file called logger.properties:

# create a category called myco.foo, set it’s level to INFO, and set the appender to myAppen (you can name this anything, but keep it simple)
log4j.category.myco.foo=INFO, myAppen
# myAppen is set to be a FileAppender.
log4j.appender.myAppen =org.apache.log4j.RollingFileAppender
log4j.appender.myAppen.File=/usr/local/cf7/htdocs/sampleApp/logs/sample.log
# we’ll use a standard layout
log4j.appender.myAppen.layout=org.apache.log4j.PatternLayout
log4j.appender.myAppen.layout.ConversionPattern=%-4r [%t] %-5p %c - %m%n
# and set the filesize limit and backup file
log4j.appender.myAppen.MaxFileSize=100KB
log4j.appender.myAppen.MaxBackupIndex=1

Now to get log4j running you just need to load this config file. The best place for this is probably in Application.cfm, as apposed to somewhere buried in your code. One thing to note, though. Once log4j is configured, it’s going to be running until you’re cf server/instance is restarted, so if you want to stop logging, you’ll need to remove the configuration code and restart cf. So here’s my Application.cfc:

<cfscript>
if (NOT IsDefined("application.loggerInit")) {
configurator = CreateObject("java", "org.apache.log4j.PropertyConfigurator");
configurator.configure('/usr/local/cf7/htdocs/sampleApp/logs/logger.properties');
application.loggerInit = true;
}
</cfscript>

Just a few things to note. I’m checking to see if if I’ve already initialized log4j, I created a ‘logs’ inside my sampleApps app folder, which contains my logger.properties config file and the samle.log file which will be created, and I’m using absolute path names in Application.cfm and in my config file. You could work around this, but… So now, you’re ready to begin logging! Let’s log a cfc being created. First I’ll retrieve the logger I created from an org.apache.log4j.Category instance and store it so other methods can use it, then use the ‘info’ method to do the logging:

<cfcomponent name="myCFC">
<cffunction name="init" returntype="myCFC">
<cfset var category = CreateObject("java", "org.apache.log4j.Category") />
<cfset variables.logger = category.getInstance('myco.foo') />
<cfset variables.logger.info('myCfc created") />
<cfreturn this />
</cffunction>
</cfcomponent>

And that’s all there is to it! Sorry about the length of the post, hopefully it’s not too much to consume, but has given you some ideas to get rolling. Happy logging!

introduction to log4j: http://logging.apache.org/log4j/docs/manual.html
log4j PatternLayout Class: http://logging.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html
ColdFusion Developer's Journal article on log4j: http://cfdj.sys-con.com/read/42122.htm

Replicating Java’s Object.toString() method in CF

2005-09-16T10:13:00.000-07:00

Here’s a little trick that may come in handy sooner or later. It’s something I desperately needed today, and was getting frustrated without it. In java if you call toString() on an object it returns the class name and the hex of its memory address. It’s quite handy for debugging things like making sure you're working with a singleton or a new object. But you can’t call toString() on a cfc. So here’s how you can get the same output in cf:

<cfset myObject = CreateObject('component','com.myco.MyObject') />
<cfset system = CreateObject('java','java.lang.System') />
<cfset objString = getMetaData(myObject).name & "@"& FormatBaseN(system.identityHashCode(myObject), 16) />

<cfdump var="#objString#" />

This will output something along the lines of 'com.myco.MyObject@fe029d42'. Just for a little teaser of what’s to come, I really wanted this for logging the creation of new cfcs with log4j. A little tutorial on using log4j with coldfusion is coming next…

I’ll make the first one a good one!

2005-09-08T18:06:00.000-07:00

I said I would write some cool stuff about ColdFusion, right? Well how about I make my first post a good one. I'm currently working with Dave Ross on a really cool project that does some interesting things concerning Mach-ii properties and external configuration files (more on that later). I’m a big mac guy, Dave’s not, so we got into an issue with filepaths, and I suggested maybe loading the config file from the classpath, since the file was really external to the application anyway.

So after I remembered that I was working in coldfusion instead of java, I came up with a cool solution, with ended up using a bit of java. A little backround info is needed to understand how this is done. Whenever you write a cfc or cfm file (or udf), cf compiles the code into a type of java class file, which is basically a normal java object. Since it is a java object you can actually use methods from the base java objects, Object and Class When you run your app, that class is loaded into the jvm that coldfusion is using through a ClassLoader, which you can obtain from the cfc, through base java objects. Before I get too far, here’s a simple example of calling a method from a cfc’s base java objects to show the type of object it is:

<cfcomponent name="test2.cfc">
<cffunction name="dumpStuff" access="public" returntype="any">
<cfdump var="#getClass().getName()#" />
</cffunction>
</cfcomponent>

Kind of cool, because getClass() is a method of java’s Object class and getName() is from the Class (that’s its name) that it returns. So going back loading files, Class has a method getClassLoader() which will return the ClassLoader I mentioned that was used to load that object into the JVM. Why do you want this? Well a ClassLoader can be used to load more that just classes, and the cool thing is it searches through a classpath to find what it’s looking for, which is configured from outside of your application, through CFAdministrator, or Jrun Admin, or through Tomcat, or a .profile file or whatever. And that makes it a very portable way to load things!

Ok, I have a feeling your still wondering why you would want to do this. Remember how I said that Dave was loading things into Mach-ii properties from a config file? Well here’s how and then maybe a little why later. This relies on another Java class, java.util.Properties, that reads a plain text file as key/value pairs and loads them into a similar construct as a cf struct, and even though this sounds like a lot of work, it’s surprisingly easy. We’ll do this in a plugin and have it happen as soon as the app starts up, so first a properties file, I’ll call it ‘myprops.properties’, it looks like this:

datasource=mydsn
mailserver=127.0.0.1
serveradmin=admin@mydomain.com

Now the plugin, with some comments:

<cfcomponent extends="MachII.framework.plugin">

<cffunction name="configure">


<cfset var props = createObject("java","java.util.Properties")/>
<cfset var propNames = 0/>
<cfset var prop = 0 />
<cfset var p = 0 />


<cfset var propFileName = “myprops.properties “ />
<cfset var classPathResource = 0 />



<cfset classPathResource = getClass().getClassLoader().getResourceAsStream(propFileName)/>

<cfset props.load(classPathResource)/>



<cfset propNames = props.keySet().toArray()/>

<cfloop from="1" to="#arraylen(propNames)#" index="p">
<cfset prop = propNames[p] />
<cfset setProperty(prop,props.get(prop))/>
</cfloop>

</cffunction>

</cfcomponent>

Since this happens as soon as the plugin is loaded, you have those properties available at application startup, and you now have application properties that are configurable from outside of the Mach-ii conf file! Cool, huh? More stuff to come soon…

Testing 1,2,3...

2005-09-08T02:13:00.000-07:00

Is this thing on? I just flew in from Philly and boy are my arms tired! No really, but...

I've got a lot of things to tell you but I'm running short on time. I promise to write a whole lot about Cold Fusion, Java, and Flash, and probably some senseless information about raisin my kids, driving my bike, and I don't know, brewing beer or something. Check back, you'll see...