geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Genender (JIRA)" <...@geronimo.apache.org>
Subject [jira] Commented: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
Date Wed, 19 Jul 2006 17:20:17 GMT
    [ http://issues.apache.org/jira/browse/DAYTRADER-7?page=comments#action_12422194 ] 
            
Jeff Genender commented on DAYTRADER-7:
---------------------------------------

"Im leaning towards Piyush's view (sorry Jason and Jeff), but on the other hand it's got me
thinking whether DayTrader should be part of Geronimo at all. If its goal is to be a platform-independent
performance benchmark application why it's part of Apache Geronimo project?"

I agree with you somewhat here, but unfortunately it is very Geronimo centric (codewise/DD)
at this point and we would need to decide if this is Geronimo or not.  From someone who lead
a team to get this working on several platforms, I can honestly say that this is/was no simple
task. and we will likely run into issues where things need to be significantly different for
each of the application servers. 

IMHO, if we strip out much of the server specific code and start using tools like XDoclet
and some of the AXIS compiling tools to be a part of the build rather than hard code the stubs
and DDs, I think this will be a very viable possibility.

We kind of do support multiple appservers.  I believe we have a set of jboss DDs in there.
 

"On to the main question, why can't we support other application servers? Why do we precompile
these JSPs at all? The more servers DayTrader supports the merrier, right?"

Being that this is a performance application, I would think that the more precompiling one
can do, the better.   However, why can't we make precompiling an option?  If we do remove
it, we may need a web option to compile the JSPs (Liferay has a really cool precompile option
build into the web application itself)...i.e. it can hit all the JSP links behind the scenes...thus
using the web server's native compiler.  But this will be a bit of a PITA since a server restart
will possibly yield a requirement to compile the JSPs once again depending on app server vendor.

Yes we can support multiple application servers, but I think the answer will  lie in leveraging
XDoclet and other compilers.




> [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers
like WebSphere
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DAYTRADER-7
>                 URL: http://issues.apache.org/jira/browse/DAYTRADER-7
>             Project: DayTrader
>          Issue Type: Bug
>    Affects Versions: 1.1
>            Reporter: Piyush Agarwal
>
> In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs
and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled
classes in the ear file. These precompiled JSPs extend and implement JspC specific classes.

> This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation.
But when the precompiled JSPs are requested from the browser it causes application server
to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific
classes in the classpath. 
> The only way I have been able to fix this problem is to remove the rules in the pom.xml
which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping
in the web.xml and then rebuild the EAR file. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message