This also makes it fairly trivial to break out Struts' own XML
configuration into multiple files, so that there could be a
"chain-config.xml" file which adhered to the spring-beans.dtd
instead of using Digester.
Sure, sounds like a good approach; I'll look into it. I'm pretty
new to Spring and haven't used multiple factories much. I'm open to
using Spring to create chain commands, as long as the configuration
file is separate from the rest of Spring services.
It took me a little while to wrap my head around it, but as I did, it
really made a lot of interesting possibilities seem reachable. For
example, it would allow a Titanium distribution to define different
bean factories for servlet vs. portlet environments where each of
those factories inherited from a core factory that was ignorant of
the differences.
Let me know if I can help close any gaps. To change what's there now
would amount to about this:
BeanFactoryLocator locator = DefaultLocatorFactory.getInstance();
BeanFactoryReference contextRef =
locator.useBeanFactory("org.apache.ti.core");
BeanFactory factory = contextRef.getFactory();
Then, in the root of the classpath (src/java/ , I guess, although
longer term, it might be cleaner to set up a separate src/resource),
create a file, "beanRefContext.xml" that looks something like this:
========== begin beanRefContext.xml ==============
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<!--
Bootstrap ApplicationContext XML config used to establish the
"Application" layer Spring context.
See
http://www.springframework.org/docs/api/org/springframework/beans/factory/access/SingletonBeanFactoryLocator.html
for more background and usage details.
-->
<!-- =========================================== -->
<!-- = com.johndeere.orderzone = -->
<!-- = "Root" ApplicationContext = -->
<!-- =========================================== -->
<bean id="org.apache.ti.core"
class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg>
<list>
<value>org/apache/ti/config/spring-config-servlet.xml</value>
</list>
</constructor-arg>
</bean>
</beans>
========== end beanRefContext.xml ==============
(Note that this ends up using ApplicationContext instead of
BeanFactory -- I'm not quite sure how you can bootstrap a pure
XMLBeanFactory by spring config alone, but there's probably a way.)
You can see how you'd add more values to the list if you wanted the
chain-config in a separate XML file from the core config.
My concerns there are YAC (Yet another context), and how will it
play with XWork, which has its own way to handle message resources?
Using multiple projects is fine as long as we can smooth out
duplications for the user.
I don't know anything about how XWork will handle message resources,
but what I'm talking about is all internal to Struts anyway, so I'm
not sure that the user needs to be concerned; this is more about an
alternative to all the LocalStrings.properties files which Struts
classes currently have to bootstrap themselves.
Until I see it, I won't argue very hard for using Spring as the
message resolver, but I am finding it handy inside my own
applications. Are there any places in Struts Ti where XWork's
message facilities are being used?
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
