Vivek Pandey wrote:
> Jacob Kessler wrote:
>> Vivek Pandey wrote:
>>> Dick Davies wrote:
>>>> Thanks for the Grizzly Rack support ; it's going to make everyone's
>>>> life much easier.
>>>>
>>>> Supporting custom Rackup files is going to make it a lot easier for
>>>> other frameworks to play too,
>>>>
>>> Thanks! Yes, that is the idea to make it easier for Ruby based
>>> frameworks to plug-in in to glassfish v3 as easy and possible.
>>>> so thanks for that. Does in make sense to add a 3rd 'application-type'
>>>> to make this clear?
>>>> i.e. you'd have 'rails', 'merb' and 'rack' as choices, and if it was
>>>> the 3rd you'd require the jruby-rackupscript parameter.
>>>>
>>>>
>>>>
>>> Let me see if I understand your comment. There is already
>>> 'jruby-applicationType' property that tells what the application
>>> type is. This is to skip auto-detection of the framework.
>>>
>>> To me, specifying 'rack' as the placeholder application type is
>>> redundant. I guess, what needs to be clarified is the relationship
>>> or behavior between jruby-rackupScript and jruby-applicationType.
>>>
>>> How does this sound:
>>>
>>> 'jruby-applicationType specifies the default frameworks supported by
>>> GlassFish v3. This skips auto-detection of the application being
>>> deployed.
>>>
>>> If both, jruby-applicationType and jruby-rackupScript are provided
>>> then jruby-applicationType is ignored and a WARNING is logged.'
>>>
>>> Jacob has been working on it so would like to know what he thinks.
>>> Jacob?
>>>
>>> -vivek.
>> As of now, jruby-applicationType takes precedence over
>> jruby-rackupScript, so if you've given an application type it will
>> ignore everything else.
> Right. Although we need to think in terms of if both the options are
> provided, what sort of error recovery will be most practical. For
> example user provides applicationType 'rails' and also provide a
> rackupScript, perhaps to override the racksup script for Rails in
> GlassFish. Should we ignore the rackupScript he has provided because
> there is 'rails' as application type? Or should it be that the rackup
> script is honored?
>
> -vivek.
To me, it seems like if both are provided, the rackupScript should be
overridden, since the rackup script would implicitly include the
application type (since it would have to start the framework on its
own). It's possible that we could merge them into a single option, with
options as "merb", "rails", or a path to a rackup script. Would that
remove the potential ambiguity and be better?
>> It sounds like Dick is suggesting that jruby-applicationType be
>> required to look for a user-specified rackup script to load.
>>
>> I think that I'd have to disagree with that, since as long as the
>> precedence relation is clearly expressed, the result is the same and
>> the user needs to set fewer properties. I think I would be in favor
>> of logging a warning if both were set that the rackup script was
>> being ignored, to prevent user confusion.
>>
>> To me, only requiring one of the options makes sense, as both of
>> those options are actually just the top of an auto-discovery routine
>> that tries to figure out what the user wanted to deploy, and the
>> system is designed to fall through gracefully if it is incorrect.
>> Thus, if rackupScript is supplied and applicationType is not, there
>> shouldn't be a noticeable performance difference or anything like that.
>> In fact, I've considered making the rackup script auto-detect only
>> (since the short-circuit of the autodetection ends up interfering a
>> bit with deploying other applications), but I've left it in since a)
>> it's useful for gem and b) it allows Rails/merb to be launched with
>> custom scripts, in case someone needs that.
>>
>>>
>>>
>>>> On Wed, Jan 14, 2009 at 12:29 AM, <glassfish_at_javadesktop.org> wrote:
>>>>
>>>>> The one-pager for GlassFish v3 Scripting is now available for
>>>>> review and comment. The official review period is one week, so
>>>>> please post your comments and feedback in the form of reply to
>>>>> this mail thread by 20 Jan 2009. We will try to consider feedback
>>>>> that arrives after that but we cannot guarantee we will be able to
>>>>> do so.
>>>>>
>>>>> You can find the one pager here:
>>>>>
>>>>> http://wiki.glassfish.java.net/attach/V3FunctionalSpecs/Scripting-one-pager.html
>>>>>
>>>>>
>>>>> Generic v3 functional specification page is:
>>>>>
>>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=V3FunctionalSpecs
>>>>>
>>>>> Thank you in advance for your comments.
>>>>>
>>>>> -vivek.
>>>>> [Message sent by forum member 'vivekp' (vivekp)]
>>>>>
>>>>> http://forums.java.net/jive/thread.jspa?messageID=325877
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>