--- Don Brown <[EMAIL PROTECTED]> wrote:Spring is broken up into 4 jars and we might only need spring-beans.jar which is 119KB, even spring.jar
On Thu, 18 Dec 2003, PILGRIM, Peter, FM wrote:
<snip />
responseWhat kind of Spring Framework classes would you want to use in Struts 2.0?
The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html
I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself.
Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc.
The major design difficulties are abstract away the request and
objects from the controller actions, and also configuration of any
other front-end objects you need along the way. To a certain extent
Commons Chain and its context leads the way regarding the former.
I see Spring as helping Struts be better structure its internal components, specifically using a BeanFactory implementation. It would not replace struts-config in any way or even be exposed directly the a Struts application. The struts-chain request processor implementation makes it easy for Struts apps to plug in IoC frameworks themselves. I totally agree Struts shouldn't become some generic IoC framework, hence my suggestion of using Spring.
The reason I think IoC is important for Struts 2.0 is for easier unit
testing, more componentized development, easier to plug in alternate
implementions of components like file upload, better dependency
management, less object references, and easier for the advanced user to
extend Struts in interesting ways. Notice these advantages are targeted
for Struts developers and advanced Struts users.
The IoC topic deserves its own thread. Spring is bloated. It contains a
DAO layer, JDBC helper library, Web MVC framework, IoC support, etc. I
don't think we should be lugging around Spring inside of Struts.
is only about 694KB. In comparison commons-collections has grown to 785KB, groan, which
is about the same size.
There are also non-technical aspects of Spring that have lowered my opinion ofOk, I'll bite..
it.
If we want IoC inside of Struts we should look at something lighter weightThe last version of hivemind I have from CVS built to 195K.
like HiveMind.
I believe that size isn't the only factor ot consider. I am not bothered by the Jar size of spring since
only those classes that are used will be loaded into the JVM. We should look at how it would fit our proposed
usage of IoC just as you suggest below.
I'd also like some focused concrete examples of how IoC
would benefit Struts internals before we decide to go that route.
David
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
