|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
What does Default JRuby Platform do in GlassFish server properties panelHello,
What is the Default JRuby Platform property for in the server's properties panel (GF3). What changes when I change this value? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelThat is the default JRuby installation used by V3 when no other
superceding location is available (e.g a project specific runtime). -Peter Chris Kutler wrote: > Hello, > > What is the Default JRuby Platform property for in the server's > properties panel (GF3). What changes when I change this value? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelNote: This applies only if V3 is started from within the IDE.
If started outside, asenv.conf (asenv.bat on windows) can specify a value for jruby.home (it is not specified by default and if not present, jruby will be unavailable to such a V3 instance). -Peter Peter Williams wrote: > That is the default JRuby installation used by V3 when no other > superceding location is available (e.g a project specific runtime). > > -Peter > > Chris Kutler wrote: >> Hello, >> >> What is the Default JRuby Platform property for in the server's >> properties panel (GF3). What changes when I change this value? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelAs all IDE JRuby projects have a JRuby installation specified, this
property is not really used by the NB Rails projects, correct? Peter Williams wrote: > Note: This applies only if V3 is started from within the IDE. > > If started outside, asenv.conf (asenv.bat on windows) can specify a > value for jruby.home (it is not specified by default and if not > present, jruby will be unavailable to such a V3 instance). > > -Peter > > > Peter Williams wrote: >> That is the default JRuby installation used by V3 when no other >> superceding location is available (e.g a project specific runtime). >> >> -Peter >> >> Chris Kutler wrote: >>> Hello, >>> >>> What is the Default JRuby Platform property for in the server's >>> properties panel (GF3). What changes when I change this value? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelDefault JRuby Platform is a V3 server instance property. Not a rails
project property. You shouldn't be able to even configure V3 as the server for a project that is configured for to use the native Ruby interpreter. Maybe I don't understand your question... -Peter Chris Kutler wrote: > As all IDE JRuby projects have a JRuby installation specified, this > property is not really used by the NB Rails projects, correct? > > Peter Williams wrote: >> Note: This applies only if V3 is started from within the IDE. >> >> If started outside, asenv.conf (asenv.bat on windows) can specify a >> value for jruby.home (it is not specified by default and if not >> present, jruby will be unavailable to such a V3 instance). >> >> -Peter >> >> >> Peter Williams wrote: >>> That is the default JRuby installation used by V3 when no other >>> superceding location is available (e.g a project specific runtime). >>> >>> -Peter >>> >>> Chris Kutler wrote: >>>> Hello, >>>> >>>> What is the Default JRuby Platform property for in the server's >>>> properties panel (GF3). What changes when I change this value? >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelIf I have a JRuby project (I can have multiple JRuby installations, such
as 1.1.3, 1.1.4), that in the project Properties window the Ruby Platform value points to a specific JRuby installation (say 1.1.3), do I need to concern myself with the values in the Server properties window? When would a Ruby programmer need to worry about that value? For what situations? Peter Williams wrote: > Default JRuby Platform is a V3 server instance property. Not a rails > project property. > > You shouldn't be able to even configure V3 as the server for a project > that is configured for to use the native Ruby interpreter. > > Maybe I don't understand your question... > > -Peter > > Chris Kutler wrote: >> As all IDE JRuby projects have a JRuby installation specified, this >> property is not really used by the NB Rails projects, correct? >> >> Peter Williams wrote: >>> Note: This applies only if V3 is started from within the IDE. >>> >>> If started outside, asenv.conf (asenv.bat on windows) can specify a >>> value for jruby.home (it is not specified by default and if not >>> present, jruby will be unavailable to such a V3 instance). >>> >>> -Peter >>> >>> >>> Peter Williams wrote: >>>> That is the default JRuby installation used by V3 when no other >>>> superceding location is available (e.g a project specific runtime). >>>> >>>> -Peter >>>> >>>> Chris Kutler wrote: >>>>> Hello, >>>>> >>>>> What is the Default JRuby Platform property for in the server's >>>>> properties panel (GF3). What changes when I change this value? >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelChris Kutler wrote:
> If I have a JRuby project (I can have multiple JRuby installations, > such as 1.1.3, 1.1.4), that in the project Properties window the Ruby > Platform value points to a specific JRuby installation (say 1.1.3), do > I need to concern myself with the values in the Server properties window? > > When would a Ruby programmer need to worry about that value? For what > situations? For when they have installed a brand new server instance on which they've never run Rails application and the very first thing they do with it is run a Web application instead. Then after that, they want their Ruby applications to run seamlessly on the same server without restarting it. It would help me greatly if I had any idea what you are using this information for. Is this for online help? -Peter > > Peter Williams wrote: >> Default JRuby Platform is a V3 server instance property. Not a rails >> project property. >> >> You shouldn't be able to even configure V3 as the server for a >> project that is configured for to use the native Ruby interpreter. >> >> Maybe I don't understand your question... >> >> -Peter >> >> Chris Kutler wrote: >>> As all IDE JRuby projects have a JRuby installation specified, this >>> property is not really used by the NB Rails projects, correct? >>> >>> Peter Williams wrote: >>>> Note: This applies only if V3 is started from within the IDE. >>>> >>>> If started outside, asenv.conf (asenv.bat on windows) can specify a >>>> value for jruby.home (it is not specified by default and if not >>>> present, jruby will be unavailable to such a V3 instance). >>>> >>>> -Peter >>>> >>>> >>>> Peter Williams wrote: >>>>> That is the default JRuby installation used by V3 when no other >>>>> superceding location is available (e.g a project specific runtime). >>>>> >>>>> -Peter >>>>> >>>>> Chris Kutler wrote: >>>>>> Hello, >>>>>> >>>>>> What is the Default JRuby Platform property for in the server's >>>>>> properties panel (GF3). What changes when I change this value? >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>> For additional commands, e-mail: dev-help@... >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelI am not using the information in the online help. Someone else wrote
the online help for that dialog box and they did not put any information in the help about this panel. I am trying to find out if I need to put this information anywhere. I have no idea if it impacts the user when running Ruby apps from the IDE. For now I will not mention this field anywhere. So, lets say that they run a web app. Then, without restarting the server, they run a Rails app from the IDE (which runs on the server). Will anything happen if they don't set the Default JRuby Platform? What if the Default JRuby Platform is not the same as the one that the NetBeans Project uses (Say one is the built-in and they are using a different one)? Peter Williams wrote: > Chris Kutler wrote: >> If I have a JRuby project (I can have multiple JRuby installations, >> such as 1.1.3, 1.1.4), that in the project Properties window the Ruby >> Platform value points to a specific JRuby installation (say 1.1.3), >> do I need to concern myself with the values in the Server properties >> window? >> >> When would a Ruby programmer need to worry about that value? For what >> situations? > For when they have installed a brand new server instance on which > they've never run Rails application and the very first thing they do > with it is run a Web application instead. Then after that, they want > their Ruby applications to run seamlessly on the same server without > restarting it. > > It would help me greatly if I had any idea what you are using this > information for. Is this for online help? > > -Peter >> >> Peter Williams wrote: >>> Default JRuby Platform is a V3 server instance property. Not a >>> rails project property. >>> >>> You shouldn't be able to even configure V3 as the server for a >>> project that is configured for to use the native Ruby interpreter. >>> >>> Maybe I don't understand your question... >>> >>> -Peter >>> >>> Chris Kutler wrote: >>>> As all IDE JRuby projects have a JRuby installation specified, this >>>> property is not really used by the NB Rails projects, correct? >>>> >>>> Peter Williams wrote: >>>>> Note: This applies only if V3 is started from within the IDE. >>>>> >>>>> If started outside, asenv.conf (asenv.bat on windows) can specify >>>>> a value for jruby.home (it is not specified by default and if not >>>>> present, jruby will be unavailable to such a V3 instance). >>>>> >>>>> -Peter >>>>> >>>>> >>>>> Peter Williams wrote: >>>>>> That is the default JRuby installation used by V3 when no other >>>>>> superceding location is available (e.g a project specific runtime). >>>>>> >>>>>> -Peter >>>>>> >>>>>> Chris Kutler wrote: >>>>>>> Hello, >>>>>>> >>>>>>> What is the Default JRuby Platform property for in the server's >>>>>>> properties panel (GF3). What changes when I change this value? >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>> For additional commands, e-mail: dev-help@... >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>> For additional commands, e-mail: dev-help@... >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelChris Kutler wrote: > I am not using the information in the online help. Someone else wrote > the online help for that dialog box and they did not put any > information in the help about this panel. > > I am trying to find out if I need to put this information anywhere. I > have no idea if it impacts the user when running Ruby apps from the > IDE. For now I will not mention this field anywhere. > > So, lets say that they run a web app. Then, without restarting the > server, they run a Rails app from the IDE (which runs on the server). > Will anything happen if they don't set the Default JRuby Platform? > What if the Default JRuby Platform is not the same as the one that the > NetBeans Project uses (Say one is the built-in and they are using a > different one)? application with the Default JRuby Platform instead of the JRuby platform that their project specifies. The alternative would be to restart the server with the correct platform specified and I have so far decided that the penalty is worse than the problem (the situation is likely to be rare anyway). It's actually quite a bit more complicated than this and I don't think documentation explaining exactly how it works would be very helpful to the end user. A blog or FAQ entry with a symptom/solution approach would be more useful, since it's the failing cases where the user may need to know how this works. -Peter > > Peter Williams wrote: >> Chris Kutler wrote: >>> If I have a JRuby project (I can have multiple JRuby installations, >>> such as 1.1.3, 1.1.4), that in the project Properties window the >>> Ruby Platform value points to a specific JRuby installation (say >>> 1.1.3), do I need to concern myself with the values in the Server >>> properties window? >>> >>> When would a Ruby programmer need to worry about that value? For >>> what situations? >> For when they have installed a brand new server instance on which >> they've never run Rails application and the very first thing they do >> with it is run a Web application instead. Then after that, they want >> their Ruby applications to run seamlessly on the same server without >> restarting it. >> >> It would help me greatly if I had any idea what you are using this >> information for. Is this for online help? >> >> -Peter >>> >>> Peter Williams wrote: >>>> Default JRuby Platform is a V3 server instance property. Not a >>>> rails project property. >>>> >>>> You shouldn't be able to even configure V3 as the server for a >>>> project that is configured for to use the native Ruby interpreter. >>>> >>>> Maybe I don't understand your question... >>>> >>>> -Peter >>>> >>>> Chris Kutler wrote: >>>>> As all IDE JRuby projects have a JRuby installation specified, >>>>> this property is not really used by the NB Rails projects, correct? >>>>> >>>>> Peter Williams wrote: >>>>>> Note: This applies only if V3 is started from within the IDE. >>>>>> >>>>>> If started outside, asenv.conf (asenv.bat on windows) can specify >>>>>> a value for jruby.home (it is not specified by default and if not >>>>>> present, jruby will be unavailable to such a V3 instance). >>>>>> >>>>>> -Peter >>>>>> >>>>>> >>>>>> Peter Williams wrote: >>>>>>> That is the default JRuby installation used by V3 when no other >>>>>>> superceding location is available (e.g a project specific runtime). >>>>>>> >>>>>>> -Peter >>>>>>> >>>>>>> Chris Kutler wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> What is the Default JRuby Platform property for in the server's >>>>>>>> properties panel (GF3). What changes when I change this value? >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>> For additional commands, e-mail: dev-help@... >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>> For additional commands, e-mail: dev-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelScroll.... Peter Williams wrote: > > > Chris Kutler wrote: >> I am not using the information in the online help. Someone else wrote >> the online help for that dialog box and they did not put any >> information in the help about this panel. >> >> I am trying to find out if I need to put this information anywhere. I >> have no idea if it impacts the user when running Ruby apps from the >> IDE. For now I will not mention this field anywhere. >> >> So, lets say that they run a web app. Then, without restarting the >> server, they run a Rails app from the IDE (which runs on the server). >> Will anything happen if they don't set the Default JRuby Platform? >> What if the Default JRuby Platform is not the same as the one that >> the NetBeans Project uses (Say one is the built-in and they are using >> a different one)? > Right now, what will happen is that GlassFish will run their Rails > application with the Default JRuby Platform instead of the JRuby > platform that their project specifies. > > The alternative would be to restart the server with the correct > platform specified and I have so far decided that the penalty is worse > than the problem (the situation is likely to be rare anyway). > > It's actually quite a bit more complicated than this and I don't think > documentation explaining exactly how it works would be very helpful to > the end user. Users never see the panel with the Default JRuby Platform (as we are not documenting it per your suggestion, and there is no reason for a user to go to this panel). The user has installed a separate JRuby installation, which is the recommended thing to do, and is using that for their projects. They install their gems into the separate JRuby installation, and not the built-in. When they run the app, it uses the built-in which does not have the necessary gems. They get errors. They have no clue that they need to go to the server's panel to fix the problem. There can also be the situation where they have updated the separate JRuby installation and not the built-in installation, and encounter errors due to version differences. > A blog or FAQ entry with a symptom/solution approach would be more > useful, since it's the failing cases where the user may need to know > how this works. In my humble opinion, I believe the information should go where the user needs it, which would be where we explain how to set the Ruby installation for the project. At that point, we will have a note or tip that the default JRuby platform should be kept in sync. eom > > -Peter >> >> Peter Williams wrote: >>> Chris Kutler wrote: >>>> If I have a JRuby project (I can have multiple JRuby installations, >>>> such as 1.1.3, 1.1.4), that in the project Properties window the >>>> Ruby Platform value points to a specific JRuby installation (say >>>> 1.1.3), do I need to concern myself with the values in the Server >>>> properties window? >>>> >>>> When would a Ruby programmer need to worry about that value? For >>>> what situations? >>> For when they have installed a brand new server instance on which >>> they've never run Rails application and the very first thing they do >>> with it is run a Web application instead. Then after that, they >>> want their Ruby applications to run seamlessly on the same server >>> without restarting it. >>> >>> It would help me greatly if I had any idea what you are using this >>> information for. Is this for online help? >>> >>> -Peter >>>> >>>> Peter Williams wrote: >>>>> Default JRuby Platform is a V3 server instance property. Not a >>>>> rails project property. >>>>> >>>>> You shouldn't be able to even configure V3 as the server for a >>>>> project that is configured for to use the native Ruby interpreter. >>>>> >>>>> Maybe I don't understand your question... >>>>> >>>>> -Peter >>>>> >>>>> Chris Kutler wrote: >>>>>> As all IDE JRuby projects have a JRuby installation specified, >>>>>> this property is not really used by the NB Rails projects, correct? >>>>>> >>>>>> Peter Williams wrote: >>>>>>> Note: This applies only if V3 is started from within the IDE. >>>>>>> >>>>>>> If started outside, asenv.conf (asenv.bat on windows) can >>>>>>> specify a value for jruby.home (it is not specified by default >>>>>>> and if not present, jruby will be unavailable to such a V3 >>>>>>> instance). >>>>>>> >>>>>>> -Peter >>>>>>> >>>>>>> >>>>>>> Peter Williams wrote: >>>>>>>> That is the default JRuby installation used by V3 when no other >>>>>>>> superceding location is available (e.g a project specific >>>>>>>> runtime). >>>>>>>> >>>>>>>> -Peter >>>>>>>> >>>>>>>> Chris Kutler wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> What is the Default JRuby Platform property for in the >>>>>>>>> server's properties panel (GF3). What changes when I change >>>>>>>>> this value? >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>> For additional commands, e-mail: dev-help@... >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>> For additional commands, e-mail: dev-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelChris Kutler wrote:
> > Scroll.... > > Peter Williams wrote: >> >> >> Chris Kutler wrote: >>> I am not using the information in the online help. Someone else >>> wrote the online help for that dialog box and they did not put any >>> information in the help about this panel. >>> >>> I am trying to find out if I need to put this information anywhere. >>> I have no idea if it impacts the user when running Ruby apps from >>> the IDE. For now I will not mention this field anywhere. >>> >>> So, lets say that they run a web app. Then, without restarting the >>> server, they run a Rails app from the IDE (which runs on the >>> server). Will anything happen if they don't set the Default JRuby >>> Platform? What if the Default JRuby Platform is not the same as the >>> one that the NetBeans Project uses (Say one is the built-in and they >>> are using a different one)? >> Right now, what will happen is that GlassFish will run their Rails >> application with the Default JRuby Platform instead of the JRuby >> platform that their project specifies. >> >> The alternative would be to restart the server with the correct >> platform specified and I have so far decided that the penalty is >> worse than the problem (the situation is likely to be rare anyway). >> >> It's actually quite a bit more complicated than this and I don't >> think documentation explaining exactly how it works would be very >> helpful to the end user. > Here is the scenario that I am imagining. > > Users never see the panel with the Default JRuby Platform (as we are > not documenting it per your suggestion, and there is no reason for a > user to go to this panel). is that "this is the JRuby platform that GlassFish will use on startup if no other platform is specified at that time." What I don't think is helpful is a highly technical description of exactly what it does and under what circumstances. If I told you the entire complex answer, you think I was crazy. But it's an unfortunate side effect of how V3 is integrated right now, how we have to handle debug mode, multiple apps, ports, etc. I'm not really happy about it. Frankly the field is a hack, but I haven't had time to think of a better way to solve the problem. I'm still hopeful I can get the server team to implement a particular feature I need to do a better job here, but so far, no dice. > > The user has installed a separate JRuby installation, which is the > recommended thing to do, and is using that for their projects. They > install their gems into the separate JRuby installation, and not the > built-in. Since when is this the recommended thing to do? Can you point me to whoever told you this or where you saw it written? If this is actually true, then why are we even bothering to include a JRuby distribution at all? (Rhetorical question, I know). You are correct in your description of what will happen in this case. What I expect is that users that are this hardcore will either not be doing web apps, or be sufficiently technical to understand what this field does. On a related note, are we expecting that ruby developers would _likely_ (not possibly) have multiple JRuby installs they are maintaining, presumably with separate groups of gems? To me, this sounds like a nightmare -- certainly supported by NetBeans, but not very nice or easy to manage in practice. -Peter > > When they run the app, it uses the built-in which does not have the > necessary gems. They get errors. They have no clue that they need to > go to the server's panel to fix the problem. > > There can also be the situation where they have updated the separate > JRuby installation and not the built-in installation, and encounter > errors due to version differences. >> A blog or FAQ entry with a symptom/solution approach would be more >> useful, since it's the failing cases where the user may need to know >> how this works. > In my humble opinion, I believe the information should go where the > user needs it, which would be where we explain how to set the Ruby > installation for the project. At that point, we will have a note or > tip that the default JRuby platform should be kept in sync. > > eom >> >> -Peter >>> >>> Peter Williams wrote: >>>> Chris Kutler wrote: >>>>> If I have a JRuby project (I can have multiple JRuby >>>>> installations, such as 1.1.3, 1.1.4), that in the project >>>>> Properties window the Ruby Platform value points to a specific >>>>> JRuby installation (say 1.1.3), do I need to concern myself with >>>>> the values in the Server properties window? >>>>> >>>>> When would a Ruby programmer need to worry about that value? For >>>>> what situations? >>>> For when they have installed a brand new server instance on which >>>> they've never run Rails application and the very first thing they >>>> do with it is run a Web application instead. Then after that, they >>>> want their Ruby applications to run seamlessly on the same server >>>> without restarting it. >>>> >>>> It would help me greatly if I had any idea what you are using this >>>> information for. Is this for online help? >>>> >>>> -Peter >>>>> >>>>> Peter Williams wrote: >>>>>> Default JRuby Platform is a V3 server instance property. Not a >>>>>> rails project property. >>>>>> >>>>>> You shouldn't be able to even configure V3 as the server for a >>>>>> project that is configured for to use the native Ruby interpreter. >>>>>> >>>>>> Maybe I don't understand your question... >>>>>> >>>>>> -Peter >>>>>> >>>>>> Chris Kutler wrote: >>>>>>> As all IDE JRuby projects have a JRuby installation specified, >>>>>>> this property is not really used by the NB Rails projects, correct? >>>>>>> >>>>>>> Peter Williams wrote: >>>>>>>> Note: This applies only if V3 is started from within the IDE. >>>>>>>> >>>>>>>> If started outside, asenv.conf (asenv.bat on windows) can >>>>>>>> specify a value for jruby.home (it is not specified by default >>>>>>>> and if not present, jruby will be unavailable to such a V3 >>>>>>>> instance). >>>>>>>> >>>>>>>> -Peter >>>>>>>> >>>>>>>> >>>>>>>> Peter Williams wrote: >>>>>>>>> That is the default JRuby installation used by V3 when no >>>>>>>>> other superceding location is available (e.g a project >>>>>>>>> specific runtime). >>>>>>>>> >>>>>>>>> -Peter >>>>>>>>> >>>>>>>>> Chris Kutler wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> What is the Default JRuby Platform property for in the >>>>>>>>>> server's properties panel (GF3). What changes when I change >>>>>>>>>> this value? >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: dev-help@... >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>>> For additional commands, e-mail: dev-help@... >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>>> For additional commands, e-mail: dev-help@... >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>>> For additional commands, e-mail: dev-help@... >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@... >>>> For additional commands, e-mail: dev-help@... >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@... >>> For additional commands, e-mail: dev-help@... >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panel> I didn't mean "Don't document it at all". I think all you need to say > is that "this is the JRuby platform that GlassFish will use on startup > if no other platform is specified at that time." I am very dense and thus I keep needing to ask questions so that I make sure that I am understanding you. I am sure everyone else finds the above clear but you need to be more patience with the non-technical like me. If Idon't understand it, I won't be able to tell the truth > this is the JRuby platform that GlassFish will use on startup I think this is saying that GlassFishes uses the JRuby platform on startup for some reason. Or do you mean this is the JRuby platform that GlassFish uses when it runs its deployed JRuby applications (if no other platform is specified)? > if no other platform is specified at that time Does "at that time" mean at the time that GlassFish is started? How does one specify a different platform at startup (other than the checkbox of course)? Can one specify a platform other than at startup, and how? > > What I don't think is helpful is a highly technical description of > exactly what it does and under what circumstances. Peter, I am rarely interested in under the hood stuff. It might be helpful for you to know that my questions asked in terms of user perspective. If you are thinking I am asking differently, ask me to rephrase the question. I want to know why a customer would check this box, when they should check this box, how the behavior changes, and what bad or wierd things can happen to an app when the box is checked or cleared. Especially when the UI is a hack. Those need the most attention or else the users can bang their heads for hours. > Since when is this the recommended thing to do? Can you point me to > whoever told you this or where you saw it written? It will be written in the newest NetBeans Ruby Installation documentation. This is what those of us who use the product over time are in agreement about because of many reasons, foremost of which are the complications that happen when you install a new version of the IDE. If you import your old settings the the Platform Manager will point to the bundle in the older version (which you may have deleted). All your apps will try to run this older version. If it is still around, and it is an older version of JRuby, you will get odd behavior that you didn't expect because you think the IDE is using the JRuby that is bundled with it, not the older one. If you don't import your settings, and you have apps dependent on older version things might not work until you install the older JRuby version and make it the platform for those apps. Then there is the issue with gems. You get NB 6.1, install all your gems into the JRuby under the installation. When you install the new NB, you have to reinstall all your gems. And you have to remember to install the older rails for your older apps. We will also recommend that people maintain gems repositories outside of the bundled JRuby subdirs, if they do choose to use the Bundled JRuby instead of their own separate installs. Or, JRuby 1.1.4 was patched after it was bundled with NB6.5 so you want to use the patched version. Or you want to start with the latest JRuby, if you happen to install NB after 1.1.5 comes out. Now we can write up all sorts of work arounds for each of these common cases (I see these issues in the forums). But we find the easiest and stableist thing to do is to install a JRuby installation, maintain you gems in that stable environment. And take control of your JRuby versions and upgrades. > If this is actually true, then why are we even bothering to include a > JRuby distribution at all? (Rhetorical question, I know). > I believe it is so that people can use the product out of the box for a good quick experience. > You are correct in your description of what will happen in this case. > What I expect is that users that are this hardcore will either not be > doing web apps, or be sufficiently technical to understand what this > field does. I can't take that chance > > On a related note, are we expecting that ruby developers would > _likely_ (not possibly) have multiple JRuby installs they are > maintaining, presumably with separate groups of gems? To me, this > sounds like a nightmare -- certainly supported by NetBeans, but not > very nice or easy to manage in practice. An interesting thing to ponder. I will ask our users over on the users@... alias > > -Peter > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelChris Kutler wrote: > >> I didn't mean "Don't document it at all". I think all you need to >> say is that "this is the JRuby platform that GlassFish will use on >> startup if no other platform is specified at that time." > I am very dense and thus I keep needing to ask questions so that I > make sure that I am understanding you. I am sure everyone else finds > the above clear but you need to be more patience with the > non-technical like me. If Idon't understand it, I won't be able to > tell the truth > >> this is the JRuby platform that GlassFish will use on startup > I think this is saying that GlassFishes uses the JRuby platform on > startup for some reason. Or do you mean this is the JRuby platform > that GlassFish uses when it runs its deployed JRuby applications (if > no other platform is specified)? existing Rails has already been deployed previously (and thus will be loaded when the server starts). The path to a JRuby platform can only be supplied to GlassFish on startup. Even if the server is not started with Rails in mind, if a Rails app is subsequently deployed, the JRuby platform had better be defined or the deploy will fail. There is no way to query a running server to determine if a JRuby platform was defined when that server was started. > >> if no other platform is specified at that time > Does "at that time" mean at the time that GlassFish is started? Yes. > How does one specify a different platform at startup (other than the > checkbox of course)? If the server is not running and you "Run" your Rails application, the JRuby platform specified by that project will be the one used by GlassFish. > Can one specify a platform other than at startup, and how? No. >> >> What I don't think is helpful is a highly technical description of >> exactly what it does and under what circumstances. > Peter, I am rarely interested in under the hood stuff. It might be > helpful for you to know that my questions asked in terms of user > perspective. If you are thinking I am asking differently, ask me to > rephrase the question. I want to know why a customer would check this > box, when they should check this box, > how the behavior changes, and what bad or wierd things can happen to > an app when the box is checked or cleared. happens "under the hood". Hypothetically speaking, lots of things could happen. In practice, probably nothing. I really don't expect this particular setting to come into play that much. If I'm mistaken, I'll revisit how things work because it *shouldn't* come into play very often, if ever. > Especially when the UI is a hack. Those need the most attention or > else the users can bang their heads for hours. >> Since when is this the recommended thing to do? Can you point me to >> whoever told you this or where you saw it written? > It will be written in the newest NetBeans Ruby Installation > documentation. > > This is what those of us who use the product over time are in > agreement about because of many reasons, foremost of which are the > complications that happen when you install a new version of the IDE. > If you import your old settings the the Platform Manager will point to > the bundle in the older version (which you may have deleted). All your > apps will try to run this older version. If it is still around, and it > is an older version of JRuby, you will get odd behavior that you > didn't expect because you think the IDE is using the JRuby that is > bundled with it, not the older one. don't believe this is the only solution to this problem. But that's a topic for another discussion. Anyway, from the perspective of the end users, most of whom will only install the release version, how often do you expect they will install a new version of the IDE? I don't think it will happen very often, but I could be wrong. I don't know if we've ever computed statistics on this. > > If you don't import your settings, and you have apps dependent on > older version things might not work until you install the older JRuby > version and make it the platform for those apps. > > Then there is the issue with gems. You get NB 6.1, install all your > gems into the JRuby under the installation. When you install the new > NB, you have to reinstall all your gems. And you have to remember to > install the older rails for your older apps. We will also recommend > that people maintain gems repositories outside of the bundled JRuby > subdirs, if they do choose to use the Bundled JRuby instead of their > own separate installs. > > Or, JRuby 1.1.4 was patched after it was bundled with NB6.5 so you > want to use the patched version. Or you want to start with the latest > JRuby, if you happen to install NB after 1.1.5 comes out. > > Now we can write up all sorts of work arounds for each of these common > cases (I see these issues in the forums). But we find the easiest and > stableist thing to do is to install a JRuby installation, maintain you > gems in that stable environment. And take control of your JRuby > versions and upgrades. gems, not withstanding matching the versions of those gems the IDE was compiled against), this bothers me. I hope it doesn't become a support problem. >> If this is actually true, then why are we even bothering to include a >> JRuby distribution at all? (Rhetorical question, I know). >> > I believe it is so that people can use the product out of the box for > a good quick experience. I tend to be averse to shipping software we don't expect people to use in real life to do real work. It just adds clutter and wastes disk space. The included distribution ought to be usable and maintainable. If it's not, then it's broken and we should fix it. But again, this is a topic for another discussion. >> You are correct in your description of what will happen in this >> case. What I expect is that users that are this hardcore will either >> not be doing web apps, or be sufficiently technical to understand >> what this field does. > I can't take that chance I understand. This area could use some more polish. But there are other areas of the product that need more polish right now, at least from what's on my plate. -Peter >> >> On a related note, are we expecting that ruby developers would >> _likely_ (not possibly) have multiple JRuby installs they are >> maintaining, presumably with separate groups of gems? To me, this >> sounds like a nightmare -- certainly supported by NetBeans, but not >> very nice or easy to manage in practice. > An interesting thing to ponder. I will ask our users over on the > users@... alias >> >> -Peter >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What does Default JRuby Platform do in GlassFish server properties panelThank you Peter. I think I have the information that I need.
Peter Williams wrote: > > > Chris Kutler wrote: >> >>> I didn't mean "Don't document it at all". I think all you need to >>> say is that "this is the JRuby platform that GlassFish will use on >>> startup if no other platform is specified at that time." >> I am very dense and thus I keep needing to ask questions so that I >> make sure that I am understanding you. I am sure everyone else finds >> the above clear but you need to be more patience with the >> non-technical like me. If Idon't understand it, I won't be able to >> tell the truth >> >>> this is the JRuby platform that GlassFish will use on startup >> I think this is saying that GlassFishes uses the JRuby platform on >> startup for some reason. Or do you mean this is the JRuby platform >> that GlassFish uses when it runs its deployed JRuby applications (if >> no other platform is specified)? > Well, GlassFish only requires a JRuby reference at startup if an > existing Rails has already been deployed previously (and thus will be > loaded when the server starts). > > The path to a JRuby platform can only be supplied to GlassFish on > startup. Even if the server is not started with Rails in mind, if a > Rails app is subsequently deployed, the JRuby platform had better be > defined or the deploy will fail. There is no way to query a running > server to determine if a JRuby platform was defined when that server > was started. > >> >>> if no other platform is specified at that time >> Does "at that time" mean at the time that GlassFish is started? > Yes. >> How does one specify a different platform at startup (other than the >> checkbox of course)? > If the server is not running and you "Run" your Rails application, the > JRuby platform specified by that project will be the one used by > GlassFish. > >> Can one specify a platform other than at startup, and how? > No. >>> >>> What I don't think is helpful is a highly technical description of >>> exactly what it does and under what circumstances. >> Peter, I am rarely interested in under the hood stuff. It might be >> helpful for you to know that my questions asked in terms of user >> perspective. If you are thinking I am asking differently, ask me to >> rephrase the question. I want to know why a customer would check this >> box, when they should check this box, how the behavior changes, and >> what bad or wierd things can happen to an app when the box is checked >> or cleared. > This is part of the question where the answer is a description of > what happens "under the hood". Hypothetically speaking, lots of > things could happen. In practice, probably nothing. I really don't > expect this particular setting to come into play that much. If I'm > mistaken, I'll revisit how things work because it *shouldn't* come > into play very often, if ever. > >> Especially when the UI is a hack. Those need the most attention or >> else the users can bang their heads for hours. >>> Since when is this the recommended thing to do? Can you point me to >>> whoever told you this or where you saw it written? >> It will be written in the newest NetBeans Ruby Installation >> documentation. >> >> This is what those of us who use the product over time are in >> agreement about because of many reasons, foremost of which are the >> complications that happen when you install a new version of the IDE. >> If you import your old settings the the Platform Manager will point >> to the bundle in the older version (which you may have deleted). All >> your apps will try to run this older version. If it is still around, >> and it is an older version of JRuby, you will get odd behavior that >> you didn't expect because you think the IDE is using the JRuby that >> is bundled with it, not the older one. > It sounds like the import code could use a little more thought then. > I don't believe this is the only solution to this problem. But that's > a topic for another discussion. > > Anyway, from the perspective of the end users, most of whom will only > install the release version, how often do you expect they will install > a new version of the IDE? I don't think it will happen very often, > but I could be wrong. I don't know if we've ever computed statistics > on this. > >> >> If you don't import your settings, and you have apps dependent on >> older version things might not work until you install the older JRuby >> version and make it the platform for those apps. >> >> Then there is the issue with gems. You get NB 6.1, install all your >> gems into the JRuby under the installation. When you install the new >> NB, you have to reinstall all your gems. And you have to remember to >> install the older rails for your older apps. We will also recommend >> that people maintain gems repositories outside of the bundled JRuby >> subdirs, if they do choose to use the Bundled JRuby instead of their >> own separate installs. >> >> Or, JRuby 1.1.4 was patched after it was bundled with NB6.5 so you >> want to use the patched version. Or you want to start with the latest >> JRuby, if you happen to install NB after 1.1.5 comes out. >> >> Now we can write up all sorts of work arounds for each of these >> common cases (I see these issues in the forums). But we find the >> easiest and stableist thing to do is to install a JRuby installation, >> maintain you gems in that stable environment. And take control of >> your JRuby versions and upgrades. > Given the way the debugger is designed (around gems, including native > gems, not withstanding matching the versions of those gems the IDE was > compiled against), this bothers me. I hope it doesn't become a > support problem. > >>> If this is actually true, then why are we even bothering to include >>> a JRuby distribution at all? (Rhetorical question, I know). >>> >> I believe it is so that people can use the product out of the box for >> a good quick experience. > I tend to be averse to shipping software we don't expect people to use > in real life to do real work. It just adds clutter and wastes disk > space. The included distribution ought to be usable and > maintainable. If it's not, then it's broken and we should fix it. > But again, this is a topic for another discussion. > >>> You are correct in your description of what will happen in this >>> case. What I expect is that users that are this hardcore will >>> either not be doing web apps, or be sufficiently technical to >>> understand what this field does. >> I can't take that chance > I understand. This area could use some more polish. But there are > other areas of the product that need more polish right now, at least > from what's on my plate. > > -Peter > >>> >>> On a related note, are we expecting that ruby developers would >>> _likely_ (not possibly) have multiple JRuby installs they are >>> maintaining, presumably with separate groups of gems? To me, this >>> sounds like a nightmare -- certainly supported by NetBeans, but not >>> very nice or easy to manage in practice. >> An interesting thing to ponder. I will ask our users over on the >> users@... alias >>> >>> -Peter >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |