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
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
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
On Wed, Nov 26, 2008 at 3:07 PM, Ikai L. [email protected] 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:
-
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.
-
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
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
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
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/library/techarticles/0611_totapally/0611_totapally.html
[2] http://pastie.org/327717
Ikai L. wrote:
From: Nick S. [mailto:[email protected]]
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
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 L. 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
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