I know the technical reason. That's not my point.
My point is that a Tomcat user will have a certain expectation because
Tomcat just works that way.
Suppose they try Glassfish because of this new gee-whiz context.xml
feature that is supposed to get them up and running quickly.
And it doesn't work. Or rather, it works but not the way they are used
to, this item isn't there, and they don't know how to fix it.
Obviously we can't fix all such items (but there should be a FAQ of the
ones we know about about and the best way to resolve them). But that
begs the question "How far are we going to go, on the path to 100%
compatibility?"
-Peter
>>
>> 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 may have misunderstood your concern, but I think support for
> context.xml is irrelevant for this discussion.
>
> JSR 199 (in-memory) compilation of JSPs is a feature available only
> in GlassFish. It is not available in Tomcat. A side effect of this
> feature
> is that no java sources are generated and written to disk.
>
> When using GlassFish on Java 6, this feature is automatically turned
> on, and may be disabled by specifying the "keepGenerated" flag in
> sun-web.xml.
>
> So yes, the user experience for someone moving from Tomcat to
> GlassFish on Java 6 will be different, but the difference is due to a
> feature available in GlassFish and not in Tomcat, and has nothing to do
> with the presence or absence of context.xml.
>
>
> Jan
>