On Aug 4, 2008, at 4:25 AM, Roman Puchkovskiy wrote:
Hi.
I've faced the problem which is described here: when a tag which
extends
SimpleTagSupport (2.0 spec) is used on a JSP, jasper compiler
included in
Geronimo 2.1.1 generates code which throws
UnsupportedOperationException.
But such code is generated only when JSP is compiled with default
settings
(obviously, this is the case when precompilation is made using some
tool,
for instance Ant).
And when JSPs are compiled on the fly by Geronimo, it compiles them
correctly.
There's a global property called
org.apache.jasper.Constants.USE_INSTANCE_MANAGER_FOR_TAGS. When it's
false
(or missing) during JSP compilation, incorrect code is generated.
When it's
true (possibly, this is the case for on-the-fly generation), the
generated
code works fine.
Here's the example of code which throws exception (it's a fragment
of code
generated for one of JSPs):
com.blandware.atleap.webapp.taglib.core.ConstantsTag
_jspx_th_atleap_005fconstants_005f0 = (new
com.blandware.atleap.webapp.taglib.core.ConstantsTag());
_jsp_instancemanager.newInstance(_jspx_th_atleap_005fconstants_005f0);
Call to newInstance() throws the following:
java.lang.UnsupportedOperationException: separate instantiation and
injection is not supported
org.apache.geronimo.jasper.JasperServletContextCustomizer
$
JasperInstanceManager
.newInstance(JasperServletContextCustomizer.java:84)
com
.blandware
.atleap
.jsp.error_jsp._jspx_meth_atleap_005fconstants_005f0(error_jsp.java:
99)
com.blandware.atleap.jsp.error_jsp._jspService(error_jsp.java:62)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
com
.blandware
.atleap
.webapp
.filter
.StatisticsCollectionFilter.doFilter(StatisticsCollectionFilter.java:
75)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
org
.acegisecurity
.intercept
.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:
107)
org
.acegisecurity
.intercept
.web
.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
org
.acegisecurity
.ui
.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:
124)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
org
.acegisecurity
.providers
.anonymous
.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:
125)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
org
.acegisecurity
.wrapper
.SecurityContextHolderAwareRequestFilter
.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
org
.acegisecurity
.context
.HttpSessionContextIntegrationFilter
.doFilter(HttpSessionContextIntegrationFilter.java:249)
org.acegisecurity.util.FilterChainProxy
$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
org
.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:
149)
org
.acegisecurity
.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal
(CharacterEncodingFilter.java:96)
org
.springframework
.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:
76)
To work this around, one may set system property called
org.apache.jasper.Constants.USE_INSTANCE_MANAGER_FOR_TAGS to true
before
calling to JspC.
So, here's a little question: is it really intended to work how it
works? I
mean it's not very intiutive to set some system properties to
compile JSPs
successfully. Or, possibly, I've just misunderstood something?
How jsps work is no longer independent of the web container they are
run in. Annotation support requires that the objects for tags get
configured by the annotation support/injection system in the
container. Jasper supports two styles depending on the flag:
1. InstanceManager creates and configures the object in one call. I
like this because it's a really clean separation of concerns and can
support constructor dependency injection etc with no user/jsp code
changes.
2. the calling code creates the object and uses the InstanceManager to
inject stuff. Some tomcat people wanted this option IIRC because
calling a hardcoded constructor is slightly faster than using
reflection.
Hope this clears things up a bit
david jencks
--
View this message in context:
http://www.nabble.com/pre-compiled-JSPs-throw-exceptions-tp16498213s134p18809470.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
