Then don’t fucking use it if you don’t need it. I can completely understand if you think the added complexity is not worth the tradeoff. If you are developing a shopping cart web application, use PHP. If you are building a J2EE app for an environment that you are reasonably certain is not going to change, use the JDK, sprinkle in some Struts or other comfort tools that you can easily understand and go to work.

However, if you are developing multiple enterprise applications, and you do not know if you are going to be authenticating against an NT domain or an LDAP directory or an Oracle table for the next project, it makes a lot of sense to use a meta-framework that will let you reuse the same code, write to the same “authentication” interface, and switch the implementation out for each new deployment requirement. The added complexity of learning the framework and developing “cleanly” using SOC, IOC, etc. does add to the initial learning curve, but can pay off in a big way as the complexity of your requirements or deployment environment increases.

You seem to be hung up on the idea more than the actual project.

We could, but flamewars are funnier, IMHO. Hani would agree, if commenting on his own blog wouldn’t be strictly prohibited to him by the little green man that lives in his head. ;)

> Seriously, you really should try to look at some
> code before having such a strong opinion :-D

Let’s put it this way: should I ever have the need to integrate some of my Spring components with, uhm, a javabean named “PicoBean” written for pico, or a pojo for xwork named “XworkPojo”, I’d definitely think about using Jicarilla, before venturing into the perilous deeps of code lines such as
PicoBean bean = new PicoBean(); or
XworkPojo pojo = new XworkPojo();

or before having the foolest idea of them all, and try to integrate those components using Spring prototype IOC features.

;-)

> If your components are simple javabeans, yes, you > can run them in jicarilla.

Ah, ok, I see jicarilla’s value, now.

> If they are complex beans using lots of
> springframework features, of course you can only
> run them inside spring. Just like you basically
> can’t run EJBs inside a servlet engine.

That’s what I suspected, too.

> That can be a kind of annoying situation, since
> you might also have some components that run only
> in (say) avalon’s fortress, and you can’t make
> components from spring use components from
> fortress, nor vice versa.

This scenario is so horrible that I will have problems at falling asleep tonight: hopefully I won’t have to integrate fortress (or Merlin, or Phoenix, or ECM, …) for the rest of my life. Listen: I’ve been trying to follow the evolution of those projects for years, and all I got from it was the sad and frustrating feeling of being way too stupid to understand what they were meant for.

One day I started using Turbine, and all of a sudden I understood what was missing, and what was missing were IOC, and AOP, and neat declarative features if compared to EJBs…: then I turned back to Avalon trying to have what Turbine was missing… and before I could even have my first instance of Merlin running with anything reasonable inside Spring was here, and my life changed to a better thing, since all was clear, and there were plenty of examples, and the APIs were stable and didn’t change from one point release to the next, and the container features were immediately useful, and well documented, and Hibernate integration was simply perfect… and, ok, you understand what I feel, I think. ;) Fortress: no. Spring: yes.

>So you run your spring components in spring, your
>avalon components in avalon, and you put some glue
>in between (could be jicarilla) to make things
>work together. That’s it. I love that axle quote.

Ok. I’m happy I don’t have any Avalon component to integrate in my current architecture. If I had one, rather than keeping all those support interfaces I would strip them out and refactor the logic in beans that I could use from Spring. At this moment, what I’d like to integrate is a layer of Turbine services, where all I will have to do is convert a couple of “interceptor-ish” tricks I had done in a pre-AOP world, remove a couple of TurbineService interfaces (or TurbineSupport, don’t remember) and for the rest they will be ready to be used in a Spring world.

p.s.: you keelers trying to act as if you weren’t pissed off are really funny.

Darn! I want that title.
Does anyone know how I can get a job as a “Dimwit of the highest order”.
I image that it’s a great job with even better bene’s and pay!
–Not to mention the cool title that I’d have on my business card.

-Phil
(An even dimmer-witted keeler)

This, in turn, only puts the responsibility of good architecture on the developer.

If we could make Keel not even exist at all, and still accomplish this very simple objective, we probably would. If this contradiction is too much to grasp, then ‘marry the first girl you meet’ and couple to that codebase of the moment. At least you will never run out of work, once you are tightly coupled to that perfect girl, er uh, code base….

I think that’s all the comment this rant deserves, other than to say that I’m definitely not the only “dimwit” involved in Keel, there really are a bunch of us!

Mike

Seriously, you really should try to look at some code before having such a strong opinion :-D

If your components are simple javabeans, yes, you can run them in jicarilla. If they are complex beans using lots of springframework features, of course you can only run them inside spring. Just like you basically can’t run EJBs inside a servlet engine.

That can be a kind of annoying situation, since you might also have some components that run only in (say) avalon’s fortress, and you can’t make components from spring use components from fortress, nor vice versa.

So you run your spring components in spring, your avalon components in avalon, and you put some glue in between (could be jicarilla) to make things work together. That’s it. I love that axle quote.

>basically, nope. The smaller framework X and Y, the higher the chance of success, especially if Y is bigger than X.

Ok, so I understand the sentence “Jicarilla natively supports the use of each of these frameworks” should read “Jicarilla has some chances of success trying to embed components of smaller frameworks”, instead.

Now, since Jicarilla seems to me much smaller than, for example, Spring, I understand that the chances Jicarilla has to embed Spring components are near zero, and are only concrete when the components one uses in Spring are pure javabeans used without expectations for features offered by the framework. So, as the chances approach zero, the sentence “Jicarilla natively supports Spring components” approaches falsity. Am I wrong?

>>”components developed for them are, in 3 cases out of four, pure javabeans!!!!”
>so why can’t one run “component for framework X”
>in “framework Y”? That’s the javabeans idea, innit?

Of course it is: that’s why writing a “framework where you can run components of other frameworks” is ridiculous, if this turns out to be “using them as the pure javabeans they are”, and simply false (“basically, nope”) if you consider that (some of) the frameworks you are saying jicarilla supports are much more than IOC containers.

>> “(…) I hope you are doomed to fail.”
> thanks for reminding me why I never comment here

I agree it’s somewhat unpleasant being exposed to the inconsistency of one’s own statements…

Not commenting here wouldn’t change my hopes: it’s things such as the one I’ve pasted before, that you should keep yourself from writing.

basically, nope. The smaller framework X and Y, the higher the chance of success, especially if Y is bigger than X.

“components developed for them are, in 3 cases out of four, pure javabeans!!!!”

so why can’t one run “component for framework X” in “framework Y”? That’s the javabeans idea, innit?

“(…) I hope you are doomed to fail.”

thanks for reminding me why I never comment here :-D