Are you around on AIM or IRC? I'd be glad to chat about this :) -- Yehuda On Wed, Oct 8, 2008 at 2:30 PM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> > The goal of this is to get around needing to use warbler and the > associated mess that it generates, and allow for GlassFish to be able > to deploy merb apps using merb's directory structure (which would then > also maintain things like ability to easily edit files rather than > needing to re-warble after any change). Writing a Rack adapter does > seem like the right thing to do, though, since standards are good. So, > if nobody minds, I'll shift over to that. Bear in mind that I haven't > done much programming in Ruby at all (though I've used dynamic > languages before), so I might come across as horribly dense, for which > I apologize. > > I see in the spec that I'm going to need to invoke call() on an object > (which looks like it's a Merb::Rack::Application), and that I'm > responsible for setting up the inputs and dealing with the outputs, > all of which is fine. > > However, I don't see any invocations of call() in the adapters that > merb comes with, nor do I see a place to get the object that I'd be > invoking it on. That probably means that I'm missing something. How do > I get that object, and is there a special time that I should invoke > it? (as opposed to just within a method that GlassFish would call when > a request came in) > > Also, I know that merb supports pooling. GlassFish does pooling as > well, and it seems like a pool of pools would be a bad idea. Given > that GlassFish will be sending all incoming requests to merb in > through a single channel, should it be handling multiple merbs, or > should I let merb take care of its own pooling? If GlassFish will be > handling multiple merbs, can I safely run multiple merbs in the same > ruby (actually jruby, but whatever) instance? > > On Oct 8, 12:21 pm, "Michael Klishin" <[EMAIL PROTECTED]> > wrote: > > 2008/10/8 [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > > > > My goal is to change GlassFish so that anyone with a Merb application > > > can say "asadmin deploy /path/to/my/merb/app" and have GlassFish > > > successfully deploy that Merb app. It seems like writing the Rack > > > adapter, since it would be a component that would live outside of > > > GlassFish, would defeat that (since anyone wanting to deploy on > > > GlassFish would need to also get the adapter). Please correct me if > > > I'm wrong about that, though. > > > > But when people run Rails applications using Glassfish or other > > servlet container, they use wambler or what is it called. > > You gonna need some interface between webserver and your framework, > > and Rack provides one dead simple specification to do just that. > > > > Rationale behind Rack can be understood by reading PEP333 Rack was > > written after: > > > > http://www.python.org/dev/peps/pep-0333/#rationale-and-goals > > -- > > MK > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
