Forum: JRuby How to access third-party Java libraries from JRuby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
47df9cfb356c3ee0523cc3571b169730?d=identicon&s=25 Kenneth McDonald (Guest)
on 2008-11-26 21:46
(Received via mailing list)
I'm attempting to use MigLayout (http://www.migcalendar.com/
miglayout/) from JRuby. I've placed the .jar file in my Java
extensions folder, but the problem occurs when I try to access the
main class:

  PANEL = javax.swing.JPanel.new(net.miginfocom.swing.MigLayout.new)

I get the error message:

  undefined local variable or method `net' for main:Object (NameError)

I'm guessing that the 'java' and 'javax' namespaces are somehow
blessed by JRuby, but that, obviously, other Java namespaces aren't.
How does one access such other namespaces?

Thanks,
Ken

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

    http://xircles.codehaus.org/manage_email
47df9cfb356c3ee0523cc3571b169730?d=identicon&s=25 Kenneth McDonald (Guest)
on 2008-11-26 21:49
(Received via mailing list)
Never mind, I just found the appropriate documentation. My bad, sorry.

Ken


On Nov 26, 2008, at 2:46 PM, Kenneth McDonald wrote:

>
>   http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email
F7e175b37a4c69709ef75c28792f2b32?d=identicon&s=25 Ikai Lan (Guest)
on 2008-11-26 22:08
(Received via mailing list)
Attachment: winmail.dat (4 KB)
I'm currently running Rails 2.2 RC1 on JRuby 1.1.4 (upgrades to
appropriate versions imminent) in a WAR file on the Sun Glassfish
Application Server. The second best thing about JDBC connection pooling
is that it essentially allows us to do configuration of database
variables on the app server rather than inside the YML file. For those
of us that run multiple environments (staging, prod, integration), being
able to create a single WAR file is a godsend. However, I haven't been
able to figure out how to make this work, so I've been creating separate
WAR files for each environment. In addition, if a single server in a
cluster needs to be configured differently from the other servers, there
isn't a clear best practice for doing this. Common use cases would be
YAML configs for different Memcached setups, or things like shared
secrets for encryption that change depending on whether the application
is in a staging or production environment.

So my question is this: what are your best practices for changing
configurations on a server by server basis when doing WAR file
deployment? In the traditional Mongrel stack deployment we can follow
with a Capistrano task to symlink files. We can definitely do that too
after the WAR file is expanded, but that feels hacky to me. I was
looking at the global $servlet_context and considering using
getAttribute, but I don't believe there's any place inside the
application server that allows me to set attributes at runtime or on a
container by container basis. Another idea is to have a config file
somewhere on each server outside of the WAR deploy directory that the
Rails application simply reads from.

The ideal situation would be that I can preserve a single WAR file for a
given release, and deployment is as simple as copying the file to an
autodeploy directory without having to fire off any post-deploy hooks,
yet configuration can be centralized. On the Sun Application Server,
this would mean being able to change settings from the GUI or standard
XML files.

Ikai
526d60de6472502bb570a9df2842b33b?d=identicon&s=25 Nick Sieger (Guest)
on 2008-11-26 22:19
(Received via mailing list)
On Wed, Nov 26, 2008 at 3:07 PM, Ikai Lan <ilan@linkedin.com> wrote:
>
>
> So my question is this: what are your best practices for changing configurations on a 
server by server basis when doing WAR file deployment? In the traditional Mongrel stack 
deployment we can follow with a Capistrano task to symlink files. We can definitely do 
that too after the WAR file is expanded, but that feels hacky to me. I was looking at the 
global $servlet_context and considering using getAttribute, but I don't believe there's 
any place inside the application server that allows me to set attributes at runtime or on 
a container by container basis. Another idea is to have a config file somewhere on each 
server outside of the WAR deploy directory that the Rails application simply reads from.
>
> The ideal situation would be that I can preserve a single WAR file for a given release, 
and deployment is as simple as copying the file to an autodeploy directory without having 
to fire off any post-deploy hooks, yet configuration can be centralized. On the Sun 
Application Server, this would mean being able to change settings from the GUI or standard 
XML files.
>

I'm not clear that there are any best practices here either.
Apparently it's possible to create appserver-specific configuration
inside the server using JNDI (or maybe some other approaches?) but
I've never seen an app that is deployed that way.

Other than that, I see a couple of possibilities:

1. Keep environment-specific config files in a well-known location on
each machine. I know, java webapps shouldn't access /etc or other
files outside of the deployment environment. Whatever. Deal.

2. Run a pre-deployment script on your bare war file to "cook"
additional configuration into it. I ran across a utility called
"editwar" [1,2,3] that I forked and have used with a little success,
but not in any production deployments yet. Let me know if you see any
use for it.

I'm sure there are others out there as well, and I'd be interested to
hear about them.

/Nick

[1]: http://caldersphere.rubyforge.org/editwar/
[2]: http://git.caldersphere.net/?p=editwar.git;a=summary
[3]: http://git.caldersphere.net/editwar.git/

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

    http://xircles.codehaus.org/manage_email
F7e175b37a4c69709ef75c28792f2b32?d=identicon&s=25 Ikai Lan (Guest)
on 2008-11-26 22:28
(Received via mailing list)
Thanks, Nick. #1 is the way I was headed anyway, but I was hoping
someone on this list had an elegant solution. #1 is no worse than what
anyone would do to get the "pack of Mongrels" setup going, and I have no
qualms about being a Java heretic.

Ikai
5a579b3ae2e98ebcc09403f38a390216?d=identicon&s=25 Matt Burke (Guest)
on 2008-12-01 14:22
(Received via mailing list)
We had a similar problem when we were deploying to WebSphere. We had one
local test server, and two remote servers for stage and production. We
used JNDI for all of the settings that needed to change per server.

For the database connection, you can use a direct JNDI reference (e.g.
jdbc/my_database) or an indirect JNDI references (e.g.
java:comp/env/jdbc/my_database, plus a declaration of the indirect
reference in the web.xml and a mapping at deploy time). In WebSphere,
indirect references are only allowed in the context of a web request,
which made background jobs and init code fail. So we used a direct JNDI
reference. This worked for us because we didn't try to deploy different
versions of the app to the same app server.

For the other settings (e.g. mail server, return address, etc.) we used
a resource environment provider [1], and accessed it via JNDI. I have no
idea how portable our solution is, but the code was pretty easy to pull
the config [2].

HTH,
Matt

[1]
http://www.ibm.com/developerworks/websphere/librar...
[2] http://pastie.org/327717

Ikai Lan wrote:
> From: Nick Sieger [mailto:nicksieger@gmail.com]
> deployment? In the traditional Mongrel stack deployment we can follow
> for a given release, and deployment is as simple as copying the file to
>
> use for it.
> ---------------------------------------------------------------------
> 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
54568ee7ba0c78a836e84c8756a3d681?d=identicon&s=25 Lenny Marks (Guest)
on 2008-12-01 19:56
(Received via mailing list)
We deploy JRuby/Rails apps to Tomcat and basically use java properties
files read from the class path. We install per servlet container
config files in Tomcat's shared/classes dir. This works well for us
since most of this configuration pre-dates our Jruby/Rails apps and is
the same as what we used to do for our older full java stack apps.
Even for other config files I think detecting the servlet environment
and loading from the classpath would work well.

-lenny


On Nov 26, 2008, at 4:07 PM, Ikai Lan wrote:

> I've been creating separate WAR files for each environment. In
> follow with a Capistrano task to symlink files. We can definitely do
> to an autodeploy directory without having to fire off any post-
>
>    http://xircles.codehaus.org/manage_email


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

    http://xircles.codehaus.org/manage_email
22785d4dbf585723bf60458ece0170e1?d=identicon&s=25 Joseph Athman (Guest)
on 2008-12-02 03:38
(Received via mailing list)
Do you use the same DB for each server environment?  If you have a
different
DB for each server then I would recommend putting environment variables
in a
table in your DB.  By doing that you aren't locking yourself in to a
Java
technology as part of your application.  Maybe some day you will do your
development with MRI or Rubinius or something and having something like
JNDI
baked in to your application would make that change harder than it needs
to
be.
I think this is similar to using a app server specific features in a
Java
application, it's usually a good idea to stay as flexible as possible.
Nick's #1 idea is along a similar line...your config files could be read
from any Ruby implementation which I would view as an advantage.

Joe
This topic is locked and can not be replied to.