creamy OGNL goodness
I love OGNL, but the thought of it being creamy has lessened it somewhat.
Given that it is all of that, I think this is where some of the risk comes in. It may be too big for some situation. If you only need IoC, it's a lot to bite off. If you only need AOP, what's wrong with AspectJ? And a 13MB download for a little ol' IoC container? Good grief!!!! And that is for the version *without* dependencies.First of all, don't ask a question like "what's wrong with AspectJ" in my presence unless you are prepared for the answer.
I'm quite prepared for whatever your response may be.
Going back to my above example, I'm applying advice on my order status method only in the admin application - not the front-end application. AspectJ just wouldn't work on this example.
How do you handle it with Spring? Different configuration files per application?
You could certainly do something similar using AspectJ - depending on your architecture. If they are separate .class/.jar files you could instrument them separately. Or you could have a *configuration* switch (Spring loaded!) that the aspect keyed off of whether it was in admin or front-end - or perhaps the call graph differs in a way that could be aspected specifically for only the front-end? Either way, saying it "wouldn't work" to a community full of developers is surely asking to be shown otherwise. We're the ones that always say "no problem" to whatever crazy requirement comes down the pipe.
Anyway, there are few apps where I wouldn't use Spring right now. Command-line filter type of applications are one of the few. Almost anything that I do that is interesting has many interacting pieces that would be better served by configuration.
I certainly agree with that last sentence. And I'm pleased to see Rick wire up jython as a way to do this configuration. I'm leaning more and more towards domain-centric languages. We all have our hammers. Personally, I'd use Lucene for configuration...
Hits hits = searcher.search(new TermQuery("config", "bean.class")); // :))
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
