Hi Mat,
Hong Zhang wrote:
> Hi, Mat
> For the EE deployment scenario, the archive will be
> expanded/processed on DAS, then the applications bits will be
> synchronized to the instance and loaded from there.
> The generated/xml files are written out during the archive
> processing on DAS. The jsp-param element was not written out in the
> generated sun-web.xml because the jsp-param element is not a declared
> element in the sun-web-app dtd.
Yes, the correct way to specify any JSP config params in sun-web.xml is via
the <jsp-config> element, as in:
<jsp-config>
<property name="aaa" value="bbb" />
<property name="xxx" value="yyy" />
...
</jsp-config>
Something like:
<jsp-descriptor>
<jsp-param>
<param-name>noTryBlocks</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
violates the DTD governing sun-web.xml.
> The generated/xml files will be synchronized to the instance, and the
> instance loads the deployment descriptors from there which does not
> contain the jsp-param element.
> Jan, any thoughts on this? Also you pointed out in this email
> thread
>
> http://forum.java.sun.com/thread.jspa?threadID=662697&messageID=9659309
I'm not familiar with the "noTryBlocks" parameter, and I don't think it
was ever supported
by Sun. I've done some research, and it looks like this options is
specific to WebLogic.
As mentioned earlier, there would also be no need for such an option in
GlassFish,
since the JSP compiler in GlassFish already implements several
strategies to avoid
the issue at hand, namely:
- Removal of nested try blocks (but there is still a try block for the
main method)
- Custom tag invocations are implemented as separate methods (unless the
body
of the custom tag invocation contains scriptlets)
Therefore, if you run into the "code too large for try statement" on
GlassFish,
the "noTryBlocks" parameter would not help, even if it existed, since
GlassFish
automatically avoids nested try/catch blocks, which is what
"noTryBlocks" is all
about.
The only way around would be to refactor your JSP into smaller chunks
included via <jsp:include>.
Jan
>
> that this jsp-param approach is no longer needed in glassfish
> v1/v2 as the jsp container has made a number of changes. Should it
> have worked for this usecase without any modification in the sun-web.xml?
>
> Thanks,
>
> - Hong
>
>
>
> Lambeth, Mathew (GE Money) wrote:
>
>> Thanks for your help.
>>
>> As per the article I have updated the sun-web.xml in the WAR file, it
>> has had no effect, but there is a discrepency....
>>
>> The file correctly deployed to:
>>
>> /ecomm/appsrv/glassfish/domains/domain1/applications/j2ee-modules/eapps-client/WEB-INF/sun-web.xml
>>
>>
>> And appears as follows.....
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD
>> Application Server 8.0 Servlet 2.4//EN"
>> "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-0.dtd">
>> <sun-web-app xmlns="http://java.sun.com/xml/ns/j2ee">
>> <context-root>/eapps-client</context-root>
>> <class-loader delegate="false"/>
>> <jsp-descriptor>
>> <jsp-param>
>> <param-name>noTryBlocks</param-name>
>> <param-value>true</param-value>
>> </jsp-param>
>> </jsp-descriptor>
>> </sun-web-app>
>>
>> Which also seems to have gone accross to the node agents path at:
>>
>> /ecomm/appsrv/glassfish/nodeagents/ge_server01_node_agent/ge_server01_client/applications/j2ee-modules/eapps-client/WEB-INF/sun-web.xml
>>
>>
>> But then there is a different copy with the seame time stamp at:
>>
>> /ecomm/appsrv/glassfish/nodeagents/ge_server01_node_agent/ge_server01_client/generated/xml/j2ee-modules/eapps-client/WEB-INF/sun-web.xml
>>
>>
>> wiithout the additions.....
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD
>> Application Server 9.0 Servlet 2.5//EN"
>> http://www.sun.com/software/appserver/dtds/sun-web-app_2
>> <http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd>_5-0.dtd>
>>
>> <sun-web-app>
>> <context-root>eapps-client</context-root>
>> <class-loader delegate="false"/>
>> </sun-web-app>
>> Appologies, Im from an App Server 7 background.... at what point do
>> each of these files get created and where are they used..... Is it
>> the generated/xml file that is used at runtime hence the
>> jsp-descriptor seemingly having no effect? If so how do I get
>> glassfish to push the copy from the WAR's WEB-INF down the chain?
>>
>> I'll also post this response on the forum for others benefit.
>>
>> Kind Regards,
>>
>>
>>
>> Mat
>>
>>
>> -----Original Message-----
>> *From:* Shreedhar.Ganapathy_at_Sun.COM
>> [mailto:Shreedhar.Ganapathy_at_Sun.COM]
>> *Sent:* 02 August 2007 16:01
>> *To:* feedback_at_glassfish.dev.java.net
>> *Cc:* Lambeth, Mathew (GE Money)
>> *Subject:* Re: [Fwd: Glassfish V2 - code too large for try
>> statement]
>>
>> I hasten to add that for more focused responses on this, please
>> post your question to the glassfish users alias.
>>
>> users AT glassfish DOT dev DOT java DOT net
>>
>>
>> Shreedhar Ganapathy wrote:
>>
>>>
>>> Hi Mathew
>>> Thanks for contacting us.
>>> Not sure if you saw this but another user coincidentally just
>>> posted the following forum reference on the glassfish users alias
>>> on pretty much the same issue.
>>>
>>> http://forum.java.sun.com/thread.jspa?threadID=662697&messahttp://travela.priceline.com/pricebreakers/deal/PB_HOTVenetian_07312007.html?session_key=400011AC410011AC2007080313010932aac0666754&plf=pcln&refid=PM20070802_PB&refclickid=PB_DEALSgeID=9659309
>>>
>>>
>>> Hope this helps.
>>> regards
>>> Shreedhar
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Glassfish V2 - code too large for try statement
>>> Date: Thu, 02 Aug 2007 15:35:13 +0100
>>> From: Lambeth, Mathew (GE Money) <Mathew.Lambeth_at_ge.com>
>>> Reply-To: feedback_at_glassfish.dev.java.net
>>> To: feedback_at_glassfish.dev.java.net
>>>
>>>
>>>
>>> Hello,
>>>
>>> I wonder if anyone can help. We are currently investigating moving
>>> from Sun Application Server 7 Enterprise Edition to Glassfish v2. I
>>> have been evaluating GlassFish on a development server (build
>>> b50g-beta3) and so far so good. I have installed a number of
>>> applications from our production servers, however I have run into
>>> the above problems at runtime when trying to run a large jsp. I'm
>>> aware that the jsp is massive and not structured very well....
>>> however it is used to drive printed output, and as the strategy is
>>> to move to another printing sollution any development is out of
>>> scope for this project. The page display fine under AS7. A collegue
>>> mentioned that I can tweak the web.xml file in some servers.... is
>>> this the case?
>>>
>>> Heres the error.,..
>>>
>>> PWC6199: Generated servlet error:
>>> [javac]
>>> /ecomm/appsrv/glassfish/nodeagents/my_server01_node_agent/my_server01_client/generated/jsp/j2ee-modules/application-client/org/apache/jsp/presentation/p945_005fx_005fapplication_005fprint_005fpage_jsp.java:478:
>>> code too large for try statement
>>> [javac] try {
>>> [javac] ^
>>>
>>>
>>> Kind Regards
>>>
>>>
>>> Mat
>>>
>>>
>>> Mat Lambeth
>>> GE Money
>>> Solutions Manager
>>>
>>> T + 44 (0)113 344 7474
>>> F + 44 (0)113 344 7950
>>> D 8 450 7474
>>> E Mathew.lambeth_at_ge.com
>>> www.geconsumerfinance.com
>>>
>>> Notice: This e-mail, together with any attachments, is confidential
>>> and may contain legally privileged information. It may be read,
>>> copied and used only by the intended recipient. If you have received
>>> it in error, please notify the sender immediately by e-mail or
>>> telephone. Please then delete it from your computer without making
>>> any copies or disclosing it to any other person GE Consumer Finance
>>> is a trading style of GE Capital Bank Limited, Registered Office: 6
>>> Agar Street, London WC2N 4HR. Registered in England No. 1456283
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: feedback-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: feedback-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>
>