On Tue, Sep 8, 2009 at 6:54 PM, James Carr <james.r.c...@gmail.com> wrote:
> Eh, that's the more complicated way... struts2 autowires by name, no
> need to implement ApplicationContextAware.

I didn't realize that.  The code in SpringObjectFactory looks for
ContextAware and sets it independently and then calls autowire.  I
just assumed it did this because the Spring contexts was not
autowired.

>I think people are missing
> the point.

I did miss your point as the link you sent as part of this solved the
problem fairly well.  I thought you were looking for a different
approach.

I have not used a filter for this in the past as filtering isn't
related to setting the application context in the servlet context.  I
have subclassed ContextLoaderListener to accomplish this task.  Here
is an example:

public class ApplicationServletContextLoaderListener extends
ContextLoaderListener {
        public void contextInitialized(ServletContextEvent event){
                super.contextInitialized(event);
                ServletContext servletContext = event.getServletContext();
                final ApplicationContext ctx =
WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext);
                servletContext.setAttribute("applicationContex",
                        new AbstractMap(){
                                ApplicationContext context = ctx;
                    public Object get(Object key) {
                        if(key == null){ return null; }
                        return context.getBean(key.toString());
                    }
                    public Set entrySet(){ return Collections.EMPTY_SET; }
                        }
                );
        }
}


I do like the ability of the filter to populate a prototype object
from a request and use it in a later jsp.  I can see how this could
make simple searches easy.  Thanks for posting that.

> I got it working just fine by adding 10 properties to my action with
> appropriate getters and setters, but I'm trying to sneak around having
> to add them to my Actions because I'd rather just have them available
> in my JSPs. No big deal I guess because I got it to work by adding the
> properties to my Action and they get auto-wired by Spring, but it'd be
> REALLY nice if they were available on the context map... it looks like
> I can either writer an Interceptor to put the beans on the stack.

I have tried to avoid the discussions as to why Spring doesn't just
add the application context to the servlet context without additional
work.  This seems to be more of a Spring question than Struts. Most of
the examples I have seen use accessors in a super class to accomplish
what you are doing.  I wish I knew why.

I am confused about why doing this in an interceptor would be better
than in the action.  If you wish to expose a subset of the Spring
beans, the action solution already does that.  If you want to
generally expose the Spring beans to the page, doing it as part of web
app initialization seems like the most convenient approach.

-- 
cordially,
Marty Milligan PO Box 434, Falling Waters, WV 25419
http://milligansisland.com/ http://byteslinger.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Reply via email to