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
