cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: Jetty 7 & "can't determine modifiers of missing type org.eclipse.jetty.webapp.WebAppContext$Context" error
Date Mon, 29 Aug 2011 11:08:30 GMT
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?


Mime
View raw message