Some more information about Castle, and why we are not 1.0

March 18th, 2007

As Castle, a more than two years old project, is getting some deserved buzz, it’s a good thing to come on public and say “hey, it’s not perfect”. And I think I might be the best person to let you know what is wrong or missing with it. The good thing about OSS compared to commercial products is that nothing stop us from saying the limitations and problems. I’ll leave the comparison with other company’s strategies as an exercise to the reader.

First, what Castle Project is all about? To fully explain that, I have to give you some more information about my life.

A long long time ago, in a distant galaxy

Back to 2003 when I was a member of the Apache Avalon project I had my view of what could be a close-to-perfection IoC container. In my view it should be minimalist and yet be so easily extensible that it could handle situation we would never anticipate. That is far different from what Avalon, Hivemind and Spring tries to be. Around that time I read The Pragmatic Programmer and the orthogonality concept made a lot of sense to me, that was the almost mathematical design that should be applied to this new container.

Apache Avalon was closed due to a very disruptive community, I’ve sadly resigned from it, and a new project was started: Apache Excalibur. Again I was excited, but the community settled to be a supportive community instead of riding the tide and provide a killer IoC container to the Java community, we had the brains, we had the vote of confidence from Apache. I engaged into endless discussion about this new direction, but I can’t change the world, can I?

September of 2004 I went to London to study english and had an interview at ThoughtWorks. Met some great guys on Geek Nights, some of them I still in touch today. Was reject from ThoughtWorks because I used “final” on my variables (something that was on the guideline for Apache’s projects) and couldn’t agree that my interviewer refactorings made the code flow better (and I still can’t). So if you’re applying for TW remember to swallow your opinion and just nod, there are some very inflated egos there.

Back in Brazil, October of 2004, I was zen. Decided to sell my car and work and study on what I wanted. My passions haven’t changed since then. AI, compilers, transaction management and IoC containers. Founded Castle to provide this IoC container I have been writing for almost two years. In the meantime I was also introduced to Ruby on Rails and decided to create something for real using it. It was distant from 1.0 at the time, and I had a large amount of problems. .Net provided a much richer API than Ruby. While there was Ruby projects to fill the gap, they weren’t mature, and making everything work wasn’t easy, especially on Windows. The performance wasn’t something thrilling too. Nevertheless the simplicity offered by RoR could not be ignored.

I’ve written a book on ASP.Net WebForms, so it was hard to admit that it didn’t work as nicely as RoR. Relying on WebForms in a real, complex system led to major headaches. At this point I decided to broad Castle’s ambitious and provide a complete development stack. The major goal was to simplify our life. That was the itchy I tried to scratch: simplification.

Due to my experience on Apache Avalon I also knew what not to do to create a healthy community. Though I’ve made a lot of mistakes, I can be proud of the community fostered around Castle.

IoC and the .net camp

Though my article on Castle was well received, I understood that the .net camp wasn’t ready for IoC containers. It was wrong to push it if people are not prepared to see the benefits, and just see it as a burden (damn, I have to register components, what is that for?). I can still remember the angry reviews on blogs and blogs comments all around.

The MicroKernel (and Windsor) are the projects I most proud of, and still the projects that receive less attention. Some things that were there since the first SVN commit received some attention last week (ie interceptors support). Seems that MS has to push something to have people realizing what IoC containers are for, what interceptors could do. Having to wait for this MS pushes is kind of depressing.

Castle and the Stronghold

After being requested for consulting a few times, I decided to open a business to offer Castle related support, development and consulting. We received so many requests that shortly I had to start rejecting development and consulting requests. The good thing is that developing for so different project scenarios bring to the surface many weakness on Castle, which were fixed to proceed with the development.

That’s how the validation support came to the surface, many view components and bug fixes. The current documentation state was created in a way that we could use it, instead of always checking the source code. While this is an improvement I admit that it still lacking documents.

Offering a ‘throat to choke’ is also a good way to lowering the barriers for adoption. We know that some companies won’t embrace anything unless there’s an entity behind it that can be sued in the event of any problems.

What is missing

OSS projects have a different life cycle compared to commercial or products. On Castle we make a release and then start to implement all crazy ideas that were voiced. Stabilize the code and repeat.

Some things, in my perception, stop us from releasing a 1.0. As you will see there aren’t many, and I’m trying do decide if we should work on them now and release a 1.0, or release another Candidate and continue to work on the missing pieces.

The Component Burden, on the MicroKernel

This is somewhat difficult to explain, but stay with me. Every time you request a component from the container it might have dependencies on components with different lifestyles. For example, you might request a component that is transient, and depends on transient and pooled instances.

Today you can release the transient (root) instance, but the dependencies won’t be properly released. This is a major limitation, but fortunately 99% of scenarios do not depend on this. Anyway this is not an excuse to not implement this support.

Btw, when I say properly release, what I mean is the decommission steps won’t run and the component will not be returned to the lifecycle manager. For pooled components that means that it wont returned to the pool. Components that implement IDisposable wont have the Dispose being invoked by the container. But rest assured that the container will not hold instances creating a memory leak.

Container Scopes

Another complex usage of containers and very useful for complex situations were components (and possibly business logic) can vary depending on some external factor. The idea is to create an hierarchy of containers. The top level container contains the invariant components, or the system core. Lower in the hierarchy you’ll find container specifically set for a client, or for a host name, or for anything that indicates the necessity of a different set up.

While I’m involved with at least three projects that will require this support at some point, I still don’t have enough use cases to implement it right. Bill Pierce has implemented almost everything required, though, but there are some issues on the backlog to be resolved.

Validator component and ActiveRecord validation infrastructure

We have to drop AR validation infrastructure in favor of the new validation component. No point in maintaining two.

ActiveRecord

While AR can make you map your database in no time, it also leads to a Domain Model that is tightly coupled with your entities on the database. Sometimes this is a big problem, so careful when adopting it on an app that will ask for a richer domain model.

MonoRail’s controller testability

The TestSupport component offered by MonoRail is totally flawed. It is useful for us, as we can use it to test how MonoRail is correctly integrated with the ASP.Net API, but it useless for any enterprise project.

The approach Aaron explains on his blog is a good way to test controllers, and I think MonoRail should offer something like that out of the box. I tried to refactor it last night to accomplish that. I gave up.

I should have used TDD to code MonoRail. Using that small time window (getting home after work, dining in front of the computer while coding changes) unsurprisingly does not create the best design. That is something I can only fix on MonoRail 2.0, or with a heavy refactoring. I’m still thinking about it…

NVelocity and Brail view engines could be better

We could work on a pre-processor that could translate more pleasant constructions into method calls or directives.

I for one dislike the usage of view components from NVelocity, but there isn’t another way to integrate it with their AST. A new view engine is being considering for a long time. IronPython view engine is also on the backlog.

View component parameters bindings

Grabbing and converting data from the ComponentParams dictionary is boring. We need a way to wire this data directly to view component’s properties.

Generators

While we have a project generator, it is not enough. Creating complex html forms is repetitive. If you have the object the form should fill, we can have the computer generating the form. You can make a change here and there, and this is something I’m working on. Marc-Andre has created a Rails-like generator, and we would like to merge it with the VS.Net add in generator. Not an easy task, though.

ActiveWriter solves the ActiveRecord generation and in a divine way.

Support for .net 1.1

This is something that was requested and with some heat, but the way DynamicProxy 2 was coded makes it an almost impossible task. I’m considering dropping this support, even if that will turn some users into enemies. :-(

We tried to do it last Friday, gave up. I tried yesterday and got sick..


As you see, lots of issues to take care of, and it’s always an opportunity to consider getting involved with Castle. Rest assured it’s an experience where everyone learns a lot.

17 Responses to “Some more information about Castle, and why we are not 1.0”

Brian Says:

Nice to know the history behind it all. :)

My focus on Castle at this point is on MonoRail (though I hope to dive into the IoC stuff in a real project soon), so most of my concerns are MonoRail-related, so that’s what my opinions are based on.

* Scrap 1.1 support. It’s not worth the effort, IMO.

* A generator should be separate from your main “1.0″ project. It’s not “core”, IMO.

* Don’t worry about the limitations of view engines. They are not “core” — you should support the framework for a view engine, and let the view engines be their own projects. Again, IMO. (That’s the last time I’m saying IMO.)

* I always thought of Castle being three projects: the kernels/IoC stuff, ActiveRecord, and MonoRail. At least that’s my impression. Why not worry about each one having their own release cycle? Sure, you want the first “1.0″ release of all three to be synced, but don’t let that slow you down from saying, “I am confident that project X is good.”

Whatever you do, keep up the good work. Your trunk is more stable than most release products I’ve used, so I’m happy if you never “officially” release.

hammett Says:

Thanks for you comment, Brian. I’ve proposed this “project independence” to the PMC, and it was not well received. It’s difficult to find people wanting to add more aggravation to their own lives :-)

I partially agree on the generator, but a new release should bring a new experience. Releasing the generator or VS.Net addins later might not have the same impact, or some people won’t be willing to give it another try.

Btw I have started the MonoRail 2 code base, I appreciate some input ;-)

Brian Says:

I remember the initial check-in of the ‘empty’ MonoRail2 project and have been waiting to see more — I see you’ve added stuff. I’ll be sure to check it out.

Sorry to hear the team didn’t want to break up the projects — my experience is that such situations make things easier, not harder, but it could be the dynamics were different than yours. It may be something to revisit if (1) you notice that delays in one sub-project are delaying the inevitable 1.0 release of the rest, or (2) you realize that you are continually adding new features to some sub-projects beyond what you expected in 1.0 because the team is waiting for another sub-project to be 1.0 ready (‘feature creep’).

Do you have a writeup somewhere (or are you planning one) on the changes in Monorail2, and why this is a separate “project” from MonoRail1? (Is it that big of a change, or just separated for simplicity?)

hammett Says:

I have a very ambitious goal for MonoRail 2, but I can’t disclose it ’til I confirm it’s doable. If it is doable, then nobody would ever have a reason to use WebForms again ;-)

About the projects, I’m really focusing on the minimal to reach 1.0 as soon as possible. I’m anxious to start a new code base with a clean slate and lots of integration tests.

On top of that I’m involved with four projects at the same time, and Castle kind of gets the low priority. I’m working to fix that, but paying customer deserve special attention :-D

Steve Says:

I first heard about Castle when I was investigating different ORM approaches, which led me to investigating Active Record. I then read Ayende’s article and your articles on what Windsor can provide, I was really impressed, and I’m using it on a project of mine.

Monorail 2 sounds great. Brian made a good point about the view engines – (actually, I agree with just about every point Brian made)

Doug Says:

The history lesson is nice, and I think a lot of people will appreciate hearing from you what the release status is. I agree that the trunk is more stable than most RTM projects (if only some “enterprise” architects at big companies would bend rules of not looking at anything in RC regardless of its success in other production environments).

I second (with my uncounted vote?) Brian’s suggestions on .NET 1.1 support and not worrying about the view engines or generator for the same reasons he specified.

I’m excited to see in the latest svnupdate that there are new files for MonoRail 2, and will be taking a look at what’s there tomorrow. The buzz Castle’s received from the talk of Microsoft giving a MVC face-lift to ASP.NET is great for the community–a little competition will be healthy. Keep up the amazing work!

Brian Says:

“If it is doable, then nobody would ever have a reason to use WebForms again”

There already is no reason, thanks to MonoRail. Fortunately for me, I’m not in a corporate environment where anyone knows or cares about frameworks — they just want to know that when they click on a link, it works. That’s smart business. :)

hammett Says:

Let’s say it would be a compelling reason to managers ;-)

ASP.NET vs. MonoRail « Andrew Peters’ Blog Says:

[...] Some more information about Castle, and why we are not 1.0 [...]

goodwill Says:

I think there are a bit more things to tidy up:
1. The validator + web support are still a bit untidy. Some of the validations are not supported which should be supported properly on at least fValidate (considering the original part of fValidate does supports such option)
2. If you really want generator, my experience is better keep it like what RoR provides- command, not mouse click, its just not nice :) I tried to use nant script = VWD Express and the experience is great as VWD refresh the web project files at instant, which very much like textmate + RoR.
3. Documentations is really important… I still can’t find a really good document about njs/brailjs, which is very important to make things really funny.
Other than that, well I am already using it on my own projects, I guess action votes for itself :)

Patrick Says:

The release of 1.0 is academic for us who already read your blog. As it’s already been said the trunk is very stable. I think it makes good sense to release another RC, as not all of us will be using the trunk and the folks using the last release are missing quite a bit now! There’s a large group of people who won’t touch the trunk because it’s usually a bad idea. There are good reasons to make regular-ish ‘stable’ releases, say every 2-4 months for where castle is atm.

The Castle project is gaining some serious momentum. I think it’s important to consider the additional momentum releasing 1.0 may have. You ideally want that momentum to increase the user base and develop (in all ways) the project further. However it’ll be potentially wasted unless everything else is in place, this isn’t just about code!

Code-wise I believe it’s neutral to have things missing, but negative to have things that are confusing, particularly with limited docs. From that point of view I think ARValidation needs cutting out and the view component params need fixing soon. Obviously more documentation is needed. Also you’ll want stronghold to be stably growing to cope with the increased demand.

Lastly I personally think you’re doing a brilliant job balancing the desires of developers and realities of business. It’s tough at times.

hammett Says:

goodwill, I’m not sure what you mean. I’m not using fValidate support, will be happy to apply a patch.

We have a command line generator, but MS developer are not as fond of command line as others. So we will supply both.

You mentioned a featured introduced recently (after the RC2). that’s why it’s not documented.

hammett Says:

Yes, Patrick. Especially ‘coz now we have published ads on computer related magazines. However it’s been a nightmare finding someone to join the team, which is odd due to level of unemployment in this country… :-\

Andrew Peters’ Blog » Blog Archive » ASP.NET Web Forms vs. MonoRail Says:

[...] Some more information about Castle, and why we are not 1.0 [...]

Mike Hadlow Says:

I’ve only recently discovered the Castle Project, or rather seen the need for the Windsor Container. I’ve arrived here via TDD, here’s my blog about the journey:

http://mikehadlow.blogspot.com/2007/08/castle-projects-windsor-container-and.html

Great work!

qixing Says:

I had been using Castle Project indirectly, until I heard about MonoRail. MonoRail is a great project. I have converted one recent project to use MonoRail. Great job! Thank you so much!

Colin Jack Says:

Was wondering what the plan is for future Castle Windsor releases?

Leave a Reply