Hi Peter,
Peter Williams wrote:
> 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.
Gotcha.
> 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?"
Current expectation is that tomcat users will have to set keepGenerated
jsp-config property to set to "true" (on JDK 6) to save generated java
source. I believe we haven't particularly made changes to GlassFish to
make sure the experience is identical in this area or do we have
immediate plans to do so. I could be wrong though.
Kin-man?
Thanks,
Amy
>
> -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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>