Forum: JRuby ruby container glassfish v3 - library problem

Hello there,

I asked in irc a few hours ago, but no one could solve my problem. I
deploy a JRoR app which depends on several jar-files in glassfish v3.
Deploying as a war is not a problem. I tried out the option "Ruby
Container" in glassfish v3. This makes it possible to deploy the app out
of the directory without creating a war-file. Deploying itself works but
glassfish/ruby-container is not able to find the jar-files and the
classes. If the jars are located in the lib/ext directory of the
glassfish domain, the classes can be found. But that's not a good
approach, because I have to restart the server everytime a jar is 
changing.

Can anyone confirm this behaviour?
(And yes: I know with warbling the app, these problems are solved, but I
wanted to try out the chances the ruby container ships for
fast-deploying jror-apps)


kind regards,
marco

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Hello,

to go forward with this problem: Nick Sieger told me to put a file into
config/initializers where I load my jar files. That works so far.
The problem is that the behaviour differs from jar files which are
located in /glassfishhome/domains/domain1/lib/ext.
In detail:
(Option 1) putting jar files into project, initialize them with a script
in /config/initializers (or require them directly somewhere in the
code): Jar files are found, a class which is used in one of this jars is
not found (I use a class which loads an apache class with the
CommonClassLoader. The jar file which holds the class to be loaded is
definitely there) Error "Failed to load
org.apache.jackrabbit.core.jndi.provider.DummyInitialContextFactory
using CommonClassLoader"
(Option 2) putting jar files into
/glassfishhome/domains/domain1/lib/ext: works fine, all classes are
loaded and can be referenced. I think this is not a good option because
application-dependent libs should lie in the app dir.

Using the classes in script/console works too, so the problem should be
somewhere between jruby <--> ruby container <--> glassfish, even though
I do not really know what else is there between jruby an glassfish.
(Once again: using a war file will not cause the problems)

Any hints I can solve the problem?

kind regards,
marco

Marco Dohnke schrieb:
> approach, because I have to restart the server everytime a jar is 
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

On Fri, Feb 26, 2010 at 2:14 AM, Marco Dohnke <dohnke@bfpi.de> wrote:
> use a class which loads an apache class with the CommonClassLoader. The jar
> not really know what else is there between jruby an glassfish.
> (Once again: using a war file will not cause the problems)

I'm sorry we're not able to provide more help.

The problem here is likely in how GF V3 handles loading jar files from
an "embedded deploy" of JRoR. Or perhaps, in how it *doesn't* handle
those jars. My guess is that it's not properly binding the directory
or that perhaps OSGi is getting in the way when trying to dynamically
load those jar files. My recommendation to you would be to post to one
of the GlassFish V3 mailing lists or contact some of the folks who
have blogged about it in the past (like Arun Gupta). I believe Oracle
intends to continue supporting GF V3 and its "embedded" deploy for
alternative languages, so hopefully someone closer to the project will
be able to help you.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Hi Charlie,

I posted to the glassfish user list but until now no one was interested
in this problem. I will follow your second hint and contact maybe Arun
Gupta. He is very present in issues with glassfish. Maybe he is able to
send me a solution.
At the moment I am using the war-deploying way but I think for people
who work with glassfish it could be quite interesting to deploy directly
in the container.

Thanks for your comments, it's amazing that you post on every problem =)

kind regards,
Marco

Charles Oliver Nutter schrieb:
>> /config/initializers (or require them directly somewhere in the code): Jar
>> Using the classes in script/console works too, so the problem should be
> or that perhaps OSGi is getting in the way when trying to dynamically
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>   

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

I agree wholeheartedly. Hopefully now that the Oracle dust has
settled, we'll be able to get a better idea of the direction of
GlassFish V3's multilanguage support. We spent the past two years
promoting it, and now that it's starting to get some penetration I'd
hate to see the rug pulled out.

Let us know what you find out from Arun, please! And if I can suggest
a possible alternative without stabbing too many former colleagues in
the back, you might be interested in JBoss's Torquebox, which has a
similarly Ruby-friendly deployment model and active developers.

On Wed, Mar 3, 2010 at 1:22 AM, Marco Dohnke <dohnke@bfpi.de> wrote:
> Thanks for your comments, it's amazing that you post on every problem =)
>>>
>>> files are found, a class which is used in one of this jars is not found
>>> not a good option because application-dependent libs should lie in the
>> I'm sorry we're not able to provide more help.
>> be able to help you.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email