The pooling was factored out by passing an object pool around, which can
be obtained in any servlet like so:
getServletContext().getAttribute(RailsContextListener.RUNTIME_POOL_ATTRIBUTE);
After this change was made, the gap between "servlet" and "generic ruby
servlet" (AbstractRailsServlet) was only a few lines of code, which
didn't make sense to keep a separate class for.
I suspect we'd see that same result with other ruby based servlets, in
that once the runtime creation and pooling is factored out, there isn't
much in common between the different implementations.
To some degree, this also moves the hook in points for customization to
other places, such as the factory used to create the runtime.
Cheers
Robert
Fausto Lelli wrote:
hi,
i maybe wrong but ...
why a "single generic ruby servlet" ? I mean RailsServlet:
protected void serviceRequest(HttpServletRequest request,
HttpServletResponse response) throws Exception {
ObjectPool runtimePool = getRuntimePool();
Ruby runtime = null;
// long startTime = System.currentTimeMillis();
try {
runtime = (Ruby)runtimePool.borrowObject();
dispatchRequest(runtime, request, response);
make runtime = getRuntime() abstract and you have a piece of reusable
functionality,
where runtime pooling is a cross-cutting concern ( yes, I'm aware it
wouldn't work otherwise
in servlet container). Thus pooling would be naturally factor out. The
basic, undivisible
unit of functionality is "take a servlet request, dispatch to a
runtime, get a servlet response". User will eventually utilize this
functionality to meet their need (provided
with sensible hooks to plug in custumization, like runtime management). Or not ?
Cheers,
Fausto
On 5/29/07, Robert Egglestone <[EMAIL PROTECTED]> wrote:
Recently the runtime management was pulled out of the servlet, and a
servlet context listener created which manages a pool of runtimes which can
be used across all servlets. Currently both RailsServlet and
RailsTaskServlet make use of this pool, however I imagine it's something
that would be useful to anything requiring multiple JRuby instances.
That said, I don't feel that having a single generic ruby servlet and
trying to leverage it for a variety of purposes is necessarily the best way
to go. I'd much rather see a variety of tools (e.g. to manage runtimes),
which can be utilized by servlets for handling different situations, such as
RoR apps, or servlets implemented entirely in Ruby. This is because we've
already seen on the mailing list that people have a variety of different
ways in which they want to combine Ruby with servlets, different URL
schemes, and so forth, and it would be good to have different servlets for
these different situations.
Cheers,
Robert
Fausto Lelli wrote:
I don't see why not, althought it is more of "rails servlet" than a
"ruby servlet".
There's some rails specific assumption as it stands now. Do you mean factor
out those too ?
F.
On 5/28/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
Fausto Lelli wrote:
Hi,
I'm sorry to put in my opinion before Robert's but it always seemed to me
that the "java_servlet-rails" bridge related classes could be extracted off
to
a new common project, and deployment related things to a bunch of
container-specific subprojects (or completely different project, but
I'd say subprojects).
The "java_servlet-rails" bridge could even come in the form of a jruby-gem.
There's been some discussion and work in the JRuby side of things for a
generic "ruby servlet" that could fit this description. Perhaps there's
something here that could be made "standard" and other things (like
GoldSpike v2) could build upon that?
- Charlie
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
