On Jul 6, 2006, at 8:47 AM, Dennis Cartier wrote:
> I would like to refactor some of my monolithic applications into
> smaller chunks. With the new features in Geronimo 1.1, I am wondering
> what deployment plan would be best suited for this?
>
> For example to package my DAO classes into a jar that can be deployed
> into Geronimo to be shared amongst multiple web applications. I looked
> through the schemas and found that geronimo-module.xsd would be the
> type most suited?
>
> I am assuming that if I include a geronimo-module.xml file in the
> JAR's META-INF directory that Geronimo will be able to use it during
> deployment and I will be able to specify the dependencies for the
> particular module in it.
The file should be named geronimo-service.xml.
> Is this even necessary (or desirable) if I
> deploy the JAR file into Geronimo as a Common Lib?
>
> I am also wondering where the plugins and CAR type fit into the scheme
> of things as well.
>
> If anyone could provide more info or point me to where this
> information is online I would appreciate it. All the examples I found
> seemed to be pretty thin on content or were still for Geronimo 1.0.
There are several dimensions to what is going on here, lets see if I
can explain.
1. classloaders.
a. if you include the geronimo-service.xml file and _deploy_ the jar
either using the packaging plugin or on the command line or (I think)
through the console, you will get a module (in a car file). This
will basically represent a classloader. If you then include a
dependency on this car file in your other modules (such as j2ee
applications) each such module will have the classloader for your
classes as a parent: in other words only ONE copy of your classes
will be loaded, shared by every module that uses them.
b. if you do not include the geronimo-service.xml (or forget to
deploy it) and put the jar in the geronimo repository directly, you
can use a jar dependency in each module. In this case your jar will
be included in each module classloader, in other words each module
gets a separate copy of your classes. No car file is generated for
your jar.
2. plugins are basically a way to package up one or more car files so
they can be easily installed and transported between servers. IIUC a
plugin can also package all its dependencies, but I'm not sure of the
details.
Hope this helps,
david jencks
>
> Dennis
>
>
> --
>
> "The music business is a cruel and shallow money trench, a long
> plastic hallway where thieves and pimps run free, and good men die
> like dogs. There's also a negative side. "
>
> Hunter S. Thompson, US journalist (1939 – 2005)
|