Am 28.08.2011 12:18, schrieb Igor Malinin:
https://jira.springsource.org/browse/SPR-7678 another interesting
bug-report... I've just checked, my simplistic Cocoon example that is
basically empty web-app with just two pages eats up 500 MB right after
start!!! Is it what called "light-weight"? At least it seems that
somebody is trying to do something about this bug, but it is still
unknown when it will be fixed. Until then it is a serious problem also
for Cocoon with its heavy use of SpringAOP.
500 MB is not strictly lightweight in terms of resource consumption.
However a 500 MB JVM does not immediately imply that all that memory is
actually used and required.
I think that should be handle separately. Maybe you could share your
config and I (or someone else) takes it for a ride through a profiler?
Technically, all those solutions are available to us.
1) requires to switch to Load-Time Weaving. This might or might not
have side-effects. I couldn't even begin to speculate...
I do not understand you here... isn't it already load-time? Or do you
mean Weaving instead of Proxying? Then this is definitely not as easy
as proxying in terms of configuration.
Yep, switching to weaving from proxying.
Right now we use Spring-AOP. This solution would require to switch to
pure AspectJ.
2a) don't expose the ServletContext in the spring-configurator or
prevent it from receiving a proxy (mark as synthetic bean?)
I've verified that marking it synthetic does the think, everything
works after that. Not exposing it at all is also an option as there is
already mechanism in Spring that allows to get ServletContext injected
- ServletContextAware interface. ServletContextFactoryBean javadoc
tells that it created to avoid a dependency to Spring
ServletContextAware interface, but it implements this interface
itself, so - what is the difference, the dependency is already there?
I can't really comment on the intention behind this feature, except that
I agree that (at least now) more elegant solutions are readily available.
2b) add jetty-webapp to the dependencies of your webapp, so that the
class is visible
It is a hack that works only for "mvn jetty:run". Breaking JEE
container class-loading is not an option. Cocoon is not in the
position to dictate servlet container how to load classes.
3) Downgrade to 1.6.6
As AspectJ folks knows about the problem for long time and do nothing
to solve it we cannot expect it to be fixed any time soon. 1.6.6 is
quite old already, should Cocoon limit progress? What if someone needs
a new version of AspectJ because of new features? While it is easiest
fix I don't think Cocoon should limit its users to some specific old
versions of libraries except when there is obvious bugs in some
versions that are fixed new newer versions and not become a 'feature'.
I think 1) and 2a) are risky.
3) is odd, because we just upgraded for some reason.
2b) is quite a kludge but a very precise, rather risk-free and
completely and easily reversible one, if required.
Strongly disagree, IMHO (2a) is the only way to go.
Different standpoints lead to different views:
I'd prefer 2b) over 2a) because our framework remains unchanged.
I wouldn't have to worry about existing applications relying on that
feature, becoming unable to upgrade.
2b) would be a very specific change to the actual application that could
be reverted on the blink of an eye.
My fix with synthetic looks like this:
protected void registerComponents(Element settingsElement,
ParserContext parserContext) {
super.registerComponents(settingsElement, parserContext);
// add the servlet context as a bean
final RootBeanDefinition beanDef =
createBeanDefinition(ServletContextFactoryBean.class.getName(), null,
false);
beanDef.setSynthetic(true);
register(beanDef, ServletContext.class.getName(),
parserContext.getRegistry());
}
I could also create a patch, but it already can be easily applied.
More problems with that cocoon-spring-configurator snapshots are not
deploying currently to maven snapshots repository, i.e. - organizational.
I am even more in favor of completely removing this and use native
Spring means to inject ServletContext when needed (the
ServletContextAware). This way ServletConfig also could be injected
(with ServletConfigAware). But unfortunately it can break some
existing Cocoon 2.2 apps.
I kinda like the idea of making that bean synthetic.
A middle ground between changing existing features and providing a fix
for the problem.
Is someone aware of any downsides to this?
