On Nov 2, 2007, at 9:11 AM, Anil Arora wrote:
David, you said that 2.1 would make this mechanism easier. Well, I
got
a hold of a 2.1 binary. How would this be easier?
The part that's easier is constructing a custom server with only the
stuff you need to support your app. Getting your app to run is about
the same process. Right now to get a custom server you need to use
maven to build your configurations and assemble the server but we
will probably have a way to do it from a running server in a few days.
From what you've described so far, and assuming I can't convince you
that putting your jars in the geronimo repo is really the simplest
solution, I think your best bet is to deploy your own shared lib
configuration where you can specify the parents such as jasper, and
then use this as a parent for your app itself.
Geronimo classloaders allow you very fine control over exactly what
class is visible where, but you do have to conform to a few
conditions to use them, mostly that you organize your jars into the
repository structure. Trying to do something else such as using a
shared lib directory that gives you little control over classloader
structure doesn't work as well as using the dependency system. On
the other hand even the shared-lib gbean gives you more possibilities
than tomcat's shared-lib since you can get the jars into the
application classloader rather than into a parent classloader. The
restriction is that these classes aren't available at deployment,
just when the app is running. With a separate shared lib
configuration that you can start before deploying your app the
classes will be available for your application deployment.
hope this helps
david jencks
Anil
-----Original Message-----
From: Anil Arora [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 7:51 AM
To: user@geronimo.apache.org
Subject: RE: Migrating tomcat to geronimo
-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 31, 2007 4:54 PM
To: user@geronimo.apache.org
Subject: Re: Migrating tomcat to geronimo
On Oct 31, 2007, at 3:33 PM, Anil Arora wrote:
-----Original Message-----
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 31, 2007 3:41 PM
To: user@geronimo.apache.org
Subject: Re: Migrating tomcat to geronimo
On Oct 31, 2007, at 9:57 AM, Paul McMahan wrote:
On Oct 31, 2007, at 12:16 PM, Anil Arora wrote:
I'm doing an experiment porting our application to Geronimo
from
Tomcat. I am having a few difficulties with some of the
customization features which I need to also port.
For Tomcat, I have a custom server.xml file, in which I turn
off
hot deployment and hardcode the location of my webapplication.
I
also have a custom catalina.properties where I can stick my own
jars in the classpath. I do all of this to avoid the extra
step
of deploying that application.
So, question is whether or not I can do similar things with
Geronimo. Given the location of the Geronimo installation, I
just
want to write a script that starts the server and have it
already
know my extra jar files and the location of my webapp without
having to execute the deploy tool.
Can this be done?
I don't know of any way to bypass the deployment process for an
application in Geronimo. You can use Geronimo's hot deployment
feature to avoid some of the manual steps involved in
deployment,
but you said that you actually turned that feature off in Tomcat
so
I assume it's not an acceptable solution. There has been some
discussion about adding this type of feature so that
applications
can be run from within an Eclipse workspace directory, but I
don't
think that anything usable has taken shape yet. Feel free to
open
a feature request for this at
http://issues.apache.org/jira/browse/
GERONIMO
Maybe I'm misinterpreting what Anil is requesting, but it looked
to
me as if he might be interested in deploying his application as a
plugin, or just deploying it once and having it in the server,
and
that he is looking for some of the features we actually support.
You can include any jars you want scoped to your application
classloader by putting them in appropriate locations in the
geronimo
repo and including dependencies on them in the geronimo plan for
your
app.
Are you trying to construct a server with your app already
deployed
that you can distribute so that users can unpack and start and
your
app will be running but they can't deploy more apps? That is
really
easy to do in trunk and only slightly harder in released geronimo
versions. Basically you would turn your app into a plugin and
use
it
to construct a custom server than has only the geronimo
components
needed to support the app. If this is what you are aiming for
let
us
know and tell us which geronimo version(s) you can use and we can
give you more instructions.
thanks
david jencks
Best wishes,
Paul
Yes, this is probably a better way of saying what I want to do.
In
the
end, I do want to have something prebuilt that the users can just
run.
There's no need to deploy anything else on the server. I was
hoping to
avoid extra coding, but I'm willing to look into this.
So far I don't see why you would have to write any extra code.
Is there a way to have a custom classloader that doesn't use this
plan
mechanism? If I'm going to build custom code, I'd might as well
write
this. This would help me avoid moving lib files around. One
problem is
that these libraries are used for other command line scripts.
If I understand correctly you want the additional libraries to be in
a particular location rather than putting them in the geronimo
repository? We supply a shared-lib configuration that lets you add
all the jars in a directory into that configurations classloader, so
you might just include that as a parent of your app in the geronimo
plan. Otherwise you can include a SharedLib gbean in your
applications plan directly and the jars will be in the same
classloader as the rest of your app.
I would like to stick with a released version for stability
reasons. I
currently have 2.0.
I recommend you do the following; it may result in a slightly larger
server than you need but is quite a bit simpler on pre-2.1 than the
alternatives to get the smallest possible server.
1. start with one of the minimal geronimo servers (unless you want
e.g. the admin console, in which case you need one of the full
servers or 2.1 :-)
2. deploy your app on the server.
3. edit var/config/config.xml and remove any modules whose name ends
in -deployer (such as tomcat-deployer) (or add an attribute
load="false")
4. remove any extraneaous logs from var/log
5 zip up what's left and distribute it
If all goes well your users will get something they can unzip and
run
with no further configuration but they won't be able to deploy any
more apps on it. (If they know enough about geronimo they could re-
enable the deployers, but you can't really protect against stuff
like
that; with tomcat they could re-enable the hot deploy directory).
hope this helps!
david jencks
Thanks,
Anil
Wow, this is great information. Yeah, I'm not too worried about
people
hacking the config file if they need to later.
The other thing I need to make sure that works without hardcoding the
root directory. If I deployed the application, does the directory
get
hardcoded in the internal database?
For the shared lib bean, I've been trying to figure out to get
this to
work. I made the following change in my config.xml to test this out.
<module name="org.apache.geronimo.configs/sharedlib/2.0.2/car">
<gbean name="SharedLib">
<attribute
name="classesDirs">c:/dev/main/install,c:/dev/main/install/internal/
inte
rlace/bundles,c:/dev/main/install/interlace/bundles</attribute>
<attribute
name="libDirs">c:/dev/main/install/internal/lib,c:/dev/main/install/
lib<
/attribute>
</gbean>
</module>
However, it does not seem to be picking up classes from any specified
lib directories.
I also tried sticking this in my Geronimo-web.xml file as well.
Is there a date for the 2.1 version to come out?
Anil
