Great, I like it! The XWork messages are only for the user and not used by Ti internally at all. If using the
ApplicationContext doesn't impact the user negatively, I'm all for it.
The earliest I could make these changes would be next week, but if you are
volunteering... :)
Don
Joe Germuska wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
