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. 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
>