On Jun 26, 2013, at 12:58 PM, Christopher Schultz 
<ch...@christopherschultz.net> wrote:
> On 6/26/13 2:57 PM, Jeremy Boynes wrote:
>> 
>> You wrote in the bug that "annotation's don't make sense" - could you
>> clarify that?
> 
> Yes: I was thinking that generating classes that used annotations would
> be a good idea. In retrospect, I don't believe it would be a good idea
> -- at least not by default. Since we are generating a web-fragment,
> there's no need to use annotations. We could also cheat and not use a
> web-fragment and instead use annotations.
> 
>> I was thinking that we could have Jasper add @WebServlet("/foo.jsp")
>> to the class generated for "foo.jsp" and then that would be picked up
>> by a container as part of its normal scan.
> 
> While that is possible, I see no reason not to explicitly-map the
> servlets individually in a web-fragment. The user can then easily edit
> the single output file (web-fragment.xml) and modify it if necessary.
> For instance, maybe some JSPs shouldn't be called directly.

Perhaps this should be user-configurable (option to generate a web-fragment.xml 
or annotations on the generated classes)?

>> BTW, can't we use ServletContext#getEffectiveMajorVersion() to
>> determine the spec-version number?
> 
> Sure we can, but JspC doesn't provide a ServletContext...

It kind of does:
  
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/servlet/JspCServletContext.java?view=markup
but it also has its own versions of WebXml and JspConfig, as well as the 
JspCompilationContext and JspRuntimeContext. This is one of the areas I found 
confusing :)

As I was proposing in my other post, if we could make the compilation process 
driven entirely off a ServletContext we can separate the JSP processing from 
the context setup which should simplify its implementation. JspC would then 
handle setup of a build-time JspCServletContext in the same way Catalina sets 
up the runtime ServletContext.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to