I am carrying the Guice thread over here because I'm getting lost a bit... Don, you bring up quite a few good points and I don't want to come off as argumentative, but I don't necessarily agree with all of them... This thread can hopefully talk to the "API Problem"
You brought up a point about how you have been using webwork 2.1.7 (possibly a forked version of it to support your forked picocontainer?). I have a few struts apps, but my apps probably more exemplify typical struts2-user usage because they do not have near as many deployments as most Atlassian products. The main difference is that I have never had any problems upgrading from 2.0.x to 2.1.x or 2.1.x to 2.1.y. The main reason I can think of is that I really don't mess with internals from the web-app. My web-apps are typically Actions, Interceptors, JSPs and some Freemarker. The lack of API that you pointed to as the problem that keeps you stuck to specific versions in your products, is the problem that you've overridden internals only to see those internals change? I am not going to disagree that we don't maintain an API internally, but the basic objects (Actions, Interceptors, Results) have all remained static as far back as I've used Struts2. If we were to come up with an API, which objects/services internally are the ones that have caused you guys the biggest problems? If a cleaner, more stable API is something that would benefit you guys, I don't see a problem with making that a goal... What would concern me, though, is that when you have knowledge of the internals, you would always be tempted to override with your own implementations if you know it would be easier. To use the ol' car analogy... I know nothing of how my car runs (well, I have the basic knowledge, but you get the picture). It gets me to and from work and that is how I use it. My younger brother who runs a body shop is constantly telling me the things I should do to squeeze out an extra MPG or gain a few HP. My response is usually to ask him how his Camaro is doing... The truth is that his Camaro is sitting in his garage with about 5 half-finished projects strewn about. The example may not be clear, but what I am trying to get to is that there are really two APIs within the "struts 2 project." The main API is what I would say is visible to users: Actions, Interceptors, Results and Tag Templates. >From those objects, I believe our users can solve 95% of their problems. The other 5% I would consider the "advanced" problems that can be solved with custom implementations of internal objects like the ActionMapper or ConfigurationProvider. If you agree that there are two psuedo-APIs, and that the basic one (Actions, Interceptors, Results, etc.) is stable, then that would mean the lack of API problem really falls into the advanced API area. I would agree that we have problems here because we make changes to both XWork and Struts Core all the time to support new features or handle bugs. The solution, though, would be more complex because I like thinking that I have the flexibility to make changes to some of those interfaces/classes in the "advanced" API. I think the first step might be coming up with a list of objects that we consider the "basic" API. Then, coming up with an "advanced" or "internal" API and deciding on a support level for those objects. The current state of things, I think is the fault of too much "good design." I know that whenever I've made changes, I've tried to come up with an interface to describe the intended functionality and provided an implementation that provided the functionality (typical service/implementation separation). The problem is that we've done that *everywhere*!! So, people working on advanced products like you have at Atlassian have the ability to override/reimplement even obscure parts of Struts. I could be wrong on all counts and even looking at it incorrectly, so if you have a better description or perspective on this, feel free to slam me :) -Wes -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
