Changing to lazy-init did help some but things where still slow. I added a bit more debugging to the code that creates the ClassPathXmlApplicationContext and discovered it was being created many, many times. After adding a stack trace to the logging I realized that the following config still existed in the person directory configuration:
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="staticMethod">
<value>org.jasig.portal.RDBMServices.getDataSource</value>
</property>
</bean>
So the new RDBMServices facade, which called on the
PortalApplictionContextLocator to get an ApplicationContext (or create
one if one doesn't already exist) would be called, which started
creating the context, which caused person directory to get wired up,
which called RDBMServices ..... and it all went downhill from there,
though amazingly the unit tests still all passed.
Oh well, so the moral of the story is watch out for those recursive loops :) Back to getting Pluto 1.1 rendering. -Eric Eric Dalquist wrote:
So I'm working on 1 and it seems to solve the test problem. I'll have to see how much of a hit there is at runtime once I get the Pluto branch to the point where I'm starting up a portal.I would still be interested in hearing from folks on their views around this issue and other possible solutions.-Eric Eric Dalquist wrote:I'm working on moving the DataSource configuration from the Tomcat specific JNDI configuration to Spring beans using DBCP. I have it working and have gutted RDBMServices so it is just a facade getting the DataSource from the ApplicationContext. There is a large (well slow) problem now with running primarily unit tests though the command line tools are fairly pokey as well.The code currently sees if it is running in a ServletContext and if so uses the Spring utils to load the WebApplicationContext. If not the code will create an ApplicationContext manually to use for the handful of static facades that now pull their implementations from Spring. Since RDBMServices is used all over the place running the tests results in the ApplicationContext getting created & destroyed hundreds if not thousands of times and as more application wiring is moved in to Spring this gets slower and slower.I'm a bit at a loss as to how to deal with this. I've thought about the following options but would love to hear others thoughts or existing solutions to this same problem.1. Change the context to default to lazy-init and see if things still run correctly and if it helps. This would end up with some runtime performance penalties that the first user in the portal may get stuck with. Is there a way when loading a ApplicationContext in code to change the default lazy-init setting?2. Use the ContextSingletonBeanFactoryLocator class and segment the Spring configs so that each static facade would only load the parts of the total application context it needs when running via tests or the command line. This would add more knowledge of the Spring context configuration into the code though and I'm not sure how much difficulty would be involved in having the same configs work for the command line, tests and runtime.3. Give up on moving the DataSource code into Spring for now, create a 'dataSource' bean in the context using a static method call to RDBMServices for the beans that need to be injected with a data source.4. Write a tests specific version of RDBMServices that has its own, small, Spring config, command line tools may still be a bit slow to initialize but there aren't many of them and they aren't run that often (well they are and we would need to find a solution eventually).5. Hope that someone out there has a nice elegant solution that will solve all of my Spring config related problems.6. Leave it as is and deal with a 30 minute unit test run time. -Eric
smime.p7s
Description: S/MIME Cryptographic Signature
