[GLASSFISH-6744] gem 0.9.0 default usage throws an error Created: 07/Nov/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: arungupta Assignee: vivekp
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,744

 Description   

With gem 0.9.0, if I start it in a non-Rails, non-Merb directory, then it throws
the following error:

– cut here –
Nov 7, 2008 2:56:44 PM OSGiModuleImpl start
INFO: Started bundle org.glassfish.scripting.grizzly-jruby-module [9]
Nov 7, 2008 2:56:45 PM com.sun.grizzly.jruby.rack.RackApplicationChooser getFactory
SEVERE: Framework autodetection failed! Please set -Djruby.applicationType to a
script that will start your framework
Nov 7, 2008 2:56:45 PM org.glassfish.scripting.rails.RailsApplication <init>
SEVERE: Error creating RailsAdapter: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.glassfish.scripting.rails.RailsApplication.<init>(RailsApplication.java:94)
at org.glassfish.scripting.rails.RailsDeployer.load(RailsDeployer.java:103)
at org.glassfish.scripting.rails.RailsDeployer.load(RailsDeployer.java:64)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.load(ApplicationLifecycle.java:499)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:176)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:180)
at
com.sun.enterprise.v3.server.ApplicationLoaderInjector.postConstruct(ApplicationLoaderInjector.java:61)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:150)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:90)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:87)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:75)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:203)
at
com.sun.enterprise.v3.server.AppServerStartup$1.run(AppServerStartup.java:116)
Caused by: java.lang.IllegalStateException: No framework to start!
at
com.sun.grizzly.jruby.rack.RackApplicationChooser.getFactory(RackApplicationChooser.java:98)
at com.sun.grizzly.jruby.RailsAdapter.<init>(RailsAdapter.java:104)
at com.sun.grizzly.jruby.RubyRuntime.<init>(RubyRuntime.java:48)
... 21 more
Nov 7, 2008 2:56:45 PM org.glassfish.scripting.rails.RailsDeployer load
INFO: Loading Rails application jruby-1.1.5 at /
Nov 7, 2008 2:56:45 PM org.glassfish.scripting.rails.RailsDeployer load
SEVERE: Error registering RailsAdapter for application jruby-1.1.5
org.glassfish.api.container.EndpointRegistrationException: The endpoint adapter
is null
at
com.sun.enterprise.v3.services.impl.GrizzlyProxy.registerEndpoint(GrizzlyProxy.java:192)
at
com.sun.enterprise.v3.services.impl.GrizzlyProxy.registerEndpoint(GrizzlyProxy.java:58)
at
com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:372)
at
com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:357)
at
com.sun.enterprise.v3.services.impl.GrizzlyService.registerEndpoint(GrizzlyService.java:343)
at org.glassfish.scripting.rails.RailsDeployer.load(RailsDeployer.java:111)
at org.glassfish.scripting.rails.RailsDeployer.load(RailsDeployer.java:64)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.load(ApplicationLifecycle.java:499)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:176)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:180)
at
com.sun.enterprise.v3.server.ApplicationLoaderInjector.postConstruct(ApplicationLoaderInjector.java:61)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:150)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:90)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:87)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:75)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:203)
at
com.sun.enterprise.v3.server.AppServerStartup$1.run(AppServerStartup.java:116)
Nov 7, 2008 2:56:45 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: GlassFish v3 Prelude startup time : Felix(1236ms) startup services(4194ms)
total(5430ms)
– cut here –

A more user friendly message should instead be displayed. Gracefully shutting
down the server and displaying only the help message would be useful.



 Comments   
Comment by arungupta [ 13/Jul/09 ]

It also creates "log" and "tmp" directories which should not be the case.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-5211] JPA is not supported in JRuby directory deployment Created: 25/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: mzh777 Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jpa_blog.war     Text File jpa_blog.zip     Text File server.log    
Issuezilla Id: 5,211

 Description   

V3 nightly build of 06/21.

The build passed the JRuby automated tests with Hudson. Tried to deploy the
JRuby Blog Rails App in directory deployment, the deployment failed. See
attached stack trace in server.log. The jpa_blog app is also attached.

After using warbler to create a war file from the same app, I was able to deploy
and run the blog app at: http://localhost:8080/jpa_blog/blog . The war file is
also attached.

Note: JRuby 1.0.3 and Rails 1.2.6 are used in the tests.



 Comments   
Comment by mzh777 [ 25/Jun/08 ]

Created an attachment (id=1584)
Stack trace

Comment by mzh777 [ 25/Jun/08 ]

Created an attachment (id=1585)
Zip of directory deployment.

Comment by mzh777 [ 25/Jun/08 ]

Created an attachment (id=1586)
War file created by warbler

Comment by mzh777 [ 25/Jun/08 ]

The JPA module is at jpa_blog/WEB-INF/classes.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-7021] setCacheControl functionality is missing inside the grizzly-jruby extension Created: 11/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: mileoresko Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,021
Status Whiteboard:

v3_exclude


 Description   

I'll just paste here the contents of a java.net glassfish forum thread, I
created regarding this issue (it's relatively short):

_________________________________________________________________________

mileoresko wrote:

Hi All,

We have a problem with cache control on our glassfish app server.
We are using Sun Glassfish Enterprise Server v3 prelude b28c. We have developed
the web application with jRuby 1.1.4 and Rails 2.1.2, and deployed the
application to the Sun Glassfish Server as a folder (not a war file)
In the domain.xml file in the Sun Glassfish Server we set the setCacheControl
property to a max-age value of 300 because we want the static content to be kept
in the browser cache for 5 minutes (testing value).

<virtual-server ... >
...
<property name="setCacheControl" value="max-age=300" />
</virtual-server>

We restart the app server, run the web app, but in the http response, we see
that the cache-control response header is not used at all.
We use Firebug for diagnostics.

Could someone please confirm that this option is indeed supported
(tested/verified) on this version of Glassfish. Is there perhaps a known issue
regarding this (maybe somehow related to this kind of rails deployment?), or are
we simply doing something wrong?

Thanks

_________________________________________________________________________

Jean-Francois Arcand wrote:

Salut,

I suspect we have a bug. setCacheControl is a value originally used by
the WebContainer and not http engine (Grizzly), on which JRuby support
build on. So the setCacheControl functionality support is missing inside
the grizzly-jruby extension. Can you file an issue here:

https://glassfish.dev.java.net/servlets/ProjectIssues

Should be simple to fix.

A+

– Jeanfrancois

_________________________________________________________________________

That's it.

If it is not a problem, please inform us if and when can we expect a solution to
this problem. I have to say, I am not really familiar with the way the Glassfish
project works, but can we maybe hope for a patch or something similar, or should
we simply be patient and wait for the next release?

Thanks,

Mile



 Comments   
Comment by vivekp [ 11/Jan/09 ]

Yes, this is not implemented inside grizzly-jruby extension. This will be fixed on the glassfish v3 trunk.

We provide patches for v3 prelude only for subscription customers. I don't know if you have subscription
of glassfish v3 prelude, if not then you would need to wait till the fix happen on the v3 trunk. Other
option is that you can use some reverse proxy to serve the static content thru some light weight web
servers. I believe most of such reverse proxy supports such cache control headers.

Comment by mileoresko [ 11/Jan/09 ]

Thanks vivekp.

We do not have a subscription for glassfish. We will wait for the next trunk
release containing the fix for this issue. I am guessing we will be notified
through this thread.

We have encountered some other problems with this deployment strategy (rails app
folder on glassfish), such as: access logging doesn't work; an SSL related
exception is logged in the server.log file on every request (log level: FINER)
... I'll post these issues as well. If you are familiar with these issues, pls
inform me, so that I do not duplicate any existing reports.
Btw, I agree with your reverse proxy advice.

Thanks.

Comment by vivekp [ 28/Sep/09 ]

<virtual-server ... >
...
<property name="setCacheControl" value="max-age=300" />
</virtual-server>

setting is really meant for the web container. OTher containers such as
jruby-container would need to first provide HTTP caching mechanism in place and
then implement this configuration support. This is unlikely to get implemented
in v3 final release. Moreover its an enhancement for the jruby container.

Further in order to help you with the static caching, GlassFish v3 final release
will support fully compliant Rack support and also Rails Rack + Rails Metal -
which would include your custom Rails Framework. This simply means that you can
use Rack::Cache framework with your rails application and let it control the
static caching. Rack::Cache is pretty good caching framework and it would be as
easy as plugging it inside your environment.rb and configuring it correctly. See
http://tomayko.com/src/rack-cache/.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-7483] Enhance Rails deployment on GlassFish v2 Created: 31/Mar/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: vivekp Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 7,483

 Description   

Currently the only way a Rails application can be deployed on GlassFish v2 is as
a WAR file using warbler. Deployment as WAR file works fine but requires extra
steps in terms of how the Rails application is bundled.

GlassFish v2 should allow deployment of Rails application natively (directory
deployment), this will enable agile development as well as a RoR natural way of
development and deployment.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-10156] Unable to allow/deny access by IP or host with Glassfish gem Created: 09/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: psfblair Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,156

 Description   

Glassfish Gem 0.9.5

Currently the Glassfish gem does not permit allow/deny access by host or IP. We have Rails on the
Glassfish gem sitting behind a web server; we're trying to restrict access to Glassfish so that it can only be
accessed via the proxy. E.g., if I have Glassfish running on port 3442, I don't want my users circumventing
my web server and accessing the app by calling URLs on port 3442 directly.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





[GLASSFISH-11416] When deploying jruby apps using the jruby deployer, no granted.policy is generated to set app-specific permissions Created: 09/Jan/10  Updated: 04/Oct/10

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: bluescreen303 Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,416
Tags: 3_1-exclude

 Description   

1) I want to run multiple jruby applications on 1 domain.
2) I want to use glassfish v3's directory/jruby container based deployment
instead of creating a .war file.
3) I don't want the applications to be able to read/write each other's
sourcecode in case 1 application gets hacked.
4) I also want to be able to deploy new applications (with their own policy)
without having to restart the domain (which will take down all apps for a few
seconds).

Since server.policy changes require the domain to restart (breaking 4), I would
like to use domains/domain1/generated/policy/myapp/granted.policy
It appear this file is not generated/available for applications deployed using
the jruby container.

This forces me to either deploy the old way, or leave my apps insecure, or have
domain-restarts affecting other apps.

I think it would be nice if the jruby container based deployment would behave
like other containers regarding security (policy generation).

Now I don't know if this defect should be fixed by the security team or by the
jruby container developers, so I just picked 1.

Thanks for any feedback/fixes/workarounds in the meantime.
Mathijs



 Comments   
Comment by bluescreen303 [ 11/Jan/10 ]

to clearify myself a bit:

I'm only talking about filesystem permissions.
Since ruby apps are scripts, they are just plain text files.
Default glassfish install (even with security manager on) is to allow all
read/writes to all files/dirs. This will allow 1 hacked/bad app to change other
apps code/config, which makes it easy to disable security checks in them so they
can get hacked too.
Since glassfish (+ all apps) run under the same (os) user, I can't protect
against this by just changing file access permissions on the OS level.
Also, since (looking from java) the codeBase is jruby-home (and not the
directory containing the ruby source files), it's impossible to set different
policies for different apps using server.policy.
This means I need to use per-app policy files or leave all apps open to the
attack mentioned above.

This means that for now I still need to use .war based deployment, where per
app granted.policy is available, but complicating lots of things (migrations,
user uploads) that the ruby container was good for.

Comment by kumarjayanti [ 04/Oct/10 ]

There needs a discussion between security team and jruby container team to see how to solve this.





[GLASSFISH-3971] v3 gem: Usage of v3 gem needs to be consistent with WEBrick Created: 04/Jan/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: arungupta Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,971

 Description   

Usage of v3 Gem is different than that of WEBrick. WEBrick is invoked in the app
directory as:

jruby script/server

gem is invoked as:

jruby -S glassfish_rails <app>

outside the app directory. To provide a seamless switch, the invocation needs to
happen in similar manner.



 Comments   
Comment by craigmcc [ 05/Apr/08 ]
      • Issue 4607 has been marked as a duplicate of this issue. ***
Comment by Dhiru Pandey [ 08/Apr/08 ]

Assigning to sub-component owner

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.





Generated at Sat Feb 28 20:53:08 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.