Nice sleuthing.
Will the rdbm.properties file be used/needed any longer once you finish
with the spring-configured DataSource?
drew wills
Eric Dalquist wrote:
And as with all seemingly complicated questions I found my problem
simply by asking a question about it.
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
--
Andrew Wills
UNICON, Inc.
Office: (480) 558-2476
http://code.google.com/p/cernunnos/
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
