Okey,
but let's try to cope with the feedback given by Mingle, I think (and
hope) it can
be done without disrupting much of what already exists.
Then let Mr. Darwin in the driver seat ...
On 5/29/07, Robert Egglestone <[EMAIL PROTECTED]> wrote:
>
> 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
>
_______________________________________________
Jruby-extras-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/jruby-extras-devel
