This is a little off topic, but something I spent some time trying to overcome
a while back - how to serve static resources efficiently from within our
Servlets.
We do it this way so that we don't have to continuously modify the web.xml file
each time we create new urls. It also makes the web.xml pretty much generic
across all of our projects.
Change your web.xml and create a filter for static content so that selected
files are served using the default Servlet.
With Tomcat, this means that it will also engage the APR if you have it
configured.
It's simpler than it sounds - assume Tomcat;
Web.xml
<!-- This registers the filter for serving static resources -->
<filter>
<filter-name>Static</filter-name>
<filter-class>com.xxx.myServlet </filter-class>
</filter>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/applets/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/graphics/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/javascript/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/skins/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/styles/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Static</filter-name>
<url-pattern>/favicon.ico</url-pattern>
</filter-mapping>
Java
public class myServlet implements Filter {
ServletContext mobjServletContext;
/****************************************************************************
*
* The doFilter method of the Filter is called by the container each time a
* request/response pair is passed through the chain due to a client request
* for a resource at the end of the chain
*
* @param objRequest Request object
* @param objResponse Response object
* @param objChain Chain of other filters
*
***************************************************************************/
public void doFilter(ServletRequest objRequest, ServletResponse
objResponse, FilterChain objChain) throws IOException, ServletException {
mobjServletContext.getNamedDispatcher("default").forward(objRequest,objResponse);
}
/****************************************************************************
*
* Called by the web container to indicate to a filter that it is being
* placed into service
*
* @param objConfig Configuration object
*
***************************************************************************/
public void init(FilterConfig objConfig) {
mobjServletContext= objConfig.getServletContext();
}
/****************************************************************************
*
* Called by the web container to indicate to a filter that it is being
* taken out of service
*
***************************************************************************/
public void destroy() {
}
}
-----Original Message-----
From: Nathan Bubna [mailto:nbu...@gmail.com]
Sent: 01 September 2010 18:33
To: Velocity Users List
Subject: Re: Best Way to Load Template Without Parsing It?
+1, then you don't have to upgrade to 1.7-beta1 and edit all your
files. Great idea, Barbara!
On Wed, Sep 1, 2010 at 10:30 AM, Barbara Baughman <baugh...@utdallas.edu> wrote:
> Why not create a template for every .js file, <jsfilename>.vm that has the
> line #include("<filename.js>")
>
> or, to avoid changing the name of the file called by the ResourceLoader, do
> some creative file copying, like filename.js copied to filenamev.js
> and the filename.js is changed to just have
> #include("filenamev.js")
>
> If the js file is called within a parsed template, the following precludes
> parsing:
> #include("filename.js")
>
> Either way, the original js files will not be parsed.
>
> Easier than redesigning Velocity.
>
> Barbara Baughman
> Systems Analyst
> X2157
>
>
> Nathan Bubna wrote:
>>
>> On Wed, Sep 1, 2010 at 10:01 AM, White, Tim <tim.wh...@qwest.com> wrote:
>>>
>>> Perhaps, although we'd have to rewrite 100's of .js files to use that
>>> syntax.
>>
>> i don't think there's an easy solution here. you can hack your own
>> versions of Velocity/VelocityTools, you can restructure your app to
>> not use a dynamic rendering servlet to serve static content, or you
>> can adapt your static files to be served through a template parsing
>> system. i don't see any other options at this point.
>>
>>> It may be possible to use Tools 2.x for just this stuff through some
>>> clever URL management, but it doesn't look like the 2.x version of VVS
>>> bubbles up getContent either...
>>
>> yeah, i don't know how upgrading your Tools version would help with
>> this, nor am i at all convinced that it should give access to
>> getContent(). that's just not what it's for, and i'm not motivated to
>> put in time to support what i consider bad practice (serving static
>> content via Velocity). sorry. :(
>>
>>> On Sep 1, 2010, at 10:10 AM, Nathan Bubna wrote:
>>>
>>>> On Wed, Sep 1, 2010 at 9:02 AM, White, Tim <tim.wh...@qwest.com> wrote:
>>>>>
>>>>> Sure. We have 100k+ templates, and a massive setup to use the resource
>>>>> loaders to pull things across from numerous locations.
>>>>>
>>>>> 90% of the time what we're pulling is Velocity templates, but the
>>>>> remaining 10% is .js files and such that aren't valid velocity, so they
>>>>> break when we try to load them....
>>>>
>>>> can you use Engine 1.7-beta1? It has the textblock feature:
>>>>
>>>> #[[ this is included but not parsed,
>>>> so you can put anything here ]]#
>>>>
>>>> which you can use to keep your javascript from breaking. of course,
>>>> this still means a wee bit of parsing overhead and context
>>>> construction. but if you are serving static files through the VVS,
>>>> then i think you'll just have to live with that. it's designed only
>>>> with dynamic files in mind, where #include is the extent of static
>>>> support.
>>>>
>>>>> On Sep 1, 2010, at 9:56 AM, Nathan Bubna wrote:
>>>>>
>>>>>> Ick. Why run that stuff through the resource loaders at all? This is
>>>>>> not really an intended usage of Velocity, so don't be too surprised
>>>>>> that there isn't much (anything?) in the way of support for it. I
>>>>>> can't currently think of any way to do this via the VVS that doesn't
>>>>>> involve hacking a custom build of Velocity.
>>>>>
>>>>> This communication is the property of Qwest and may contain
>>>>> confidential or
>>>>> privileged information. Unauthorized use of this communication is
>>>>> strictly
>>>>> prohibited and may be unlawful. If you have received this
>>>>> communication
>>>>> in error, please immediately notify the sender by reply e-mail and
>>>>> destroy
>>>>> all copies of the communication and any attachments.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>>
>>>
>>> This communication is the property of Qwest and may contain confidential
>>> or
>>> privileged information. Unauthorized use of this communication is
>>> strictly
>>> prohibited and may be unlawful. If you have received this communication
>>> in error, please immediately notify the sender by reply e-mail and
>>> destroy
>>> all copies of the communication and any attachments.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>>> For additional commands, e-mail: user-h...@velocity.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
> For additional commands, e-mail: user-h...@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
For additional commands, e-mail: user-h...@velocity.apache.org
