dev@glassfish.java.net

Re: context.xml vs sun-web.xml

From: Peter Williams <Pete.Williams_at_Sun.COM>
Date: Thu, 24 May 2007 09:59:15 -0700

Amy Roh wrote:
> Peter Williams wrote:
>> Thanks for the answers. One more comment inline.
>>
>> Amy Roh wrote:
>>
>>> Peter Williams wrote:
>>>
>>>> I just read Amy's blog
>>>> (http://weblogs.java.net/blog/amyroh/archive/2007/05/context_webapp_1.html)
>>>> about a new V2 feature where context.xml from Tomcat is supported
>>>> at several levels by Sun AppServer/Glassfish and I have several
>>>> questions I need answers to:
>>>>
>>>> 1. What happens if deployed webapp contains both sun-web.xml and
>>>> context.xml? Which one will be used? Assume the data is in
>>>> conflict (e.g. the two context-root fields are different).
>>>
>>>
>>> sun-web.xml should be used.
>>>
>>>> 2. What happens if a deployed webapp containing sun-web.xml is
>>>> deployed to a server that has a global or virtual context.xml
>>>> defined? (Similar conditions to above)
>>>
>>>
>>> same as above, sun-web.xml should be used.
>>>
>>>> 3. Assume Glassfish is running on JDK 1.6 and only context.xml is
>>>> specified. Will generated java sources for JSP's be saved to disk
>>>> or not? If not, what should the user do to make this happen?
>>>
>>>
>>> AFAIK, the behavior should be the same with or without context.xml
>>> defined.
>>
>> Why would it be same?
>>
>> It's not when sun-web.xml is used (jsp-config property
>> "keepGenerated" is required for JDK 6 jsp compiler to keep .java
>> files present (for actions such as "View Servlet" in NetBeans web
>> project module).
>> Is a different jsp compiler (or different settings) used when
>> supporting this file?
>
> I meant it should use the default value ("false" for JDK 6 and "true"
> for JDK 1.5 and earlier) with or without context.xml. It shouldn't
> affect the current behavior and still uses the same jsp compiler
> (jasper). Kin-man and Jan (aka jasper experts) can probably comment
> more on this.
I should have been more clear. I checked this behavior against Tomcat
5.0, 5.5, and 6.0 on JDK 6 yesterday -- they all save generated java
source (no context.xml required). I assume this is what Tomcat users
would be used to.

Glassfish does _not_ save java source when running on JDK 6 unless the
keepGenerated jsp-config property is set to true in sun-web.xml.
Assuming Glassfish behavior w/ context.xml is no different than
sun-web.xml, Tomcat users running their apps unchanged on glassfish +
JDK 6 using this new context.xml support will not get the results they
expect.

I presume the goal is to make it easy for someone using to Tomcat to
switch to Glassfish. My overall question here is "how far are we going
to go to make the experience identical to what they are used to?"

-Peter
>
> hth,
> Amy
>
>>
>> -Peter
>>
>>>
>>> I forgot to mention other conflict cases in the blog. Basically, if
>>> contextXmlDefault for a virtual server is defined, any conflicting
>>> value will use the virtual-server's context.xml. For virtual
>>> servers without contextXmlDefault defined, global context.xml values
>>> will be used over webapp's context.xml.
>>>
>>> Thanks,
>>> Amy
>>>
>>>>
>>>> -Peter
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>