You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Dennis Cartier <de...@gmail.com> on 2006/07/06 17:47:53 UTC
Library Packaging for Geronimo 1.1
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. 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.
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)
Re: Library Packaging for Geronimo 1.1
Posted by David Jencks <da...@yahoo.com>.
On Jul 7, 2006, at 10:56 AM, Dennis Cartier wrote:
> Thanks for the help David. Your response helped to get me on the
> right track.
>
> I was able to make your method 1b working, but was unable to get 1a
> working. I get a NoClassFoundError upon deploying the WAR file during
> the Spring context initialization. I tried deploying my package as
> both a JAR file and as a CAR file (with appropriate dependency added
> to the WAR) but neither seemed to get method 1a working.
>
> My geronimo-service.xml file is attached. I am wondering if I need
> more in it as it seems pretty sparse. Some examples I found online had
> GBean entries, but since I am only hostig class libraries, I could not
> see the need.
>
> I can get by using method 1b but, 1a strikes me as being the more
> efficient desirable method of operation, unless I am misunderstanding
> what a CAR file represents.
I agree 1a is better, but I can't reproduce your problem. I'm
attaching a little maven 2 test project. mvn install builds the
servicejar jar, you can deploy it with something like
java -jar target/geronimo-1.2-SNAPSHOT/bin/deployer.jar deploy
servicejar-1.0-SNAPSHOT.jar
and the server console should print
test bean started
which indicates that the class in the jar is available for gbeans in
the plan in the jar
Then you can deploy the child plan wth something like
java -jar target/geronimo-1.2-SNAPSHOT/bin/deployer.jar deploy
geronimo-service2.xml
and the server console should print the same
test bean started
again which indicates that the class in the jar is also available to
children.
I hope this will help you figure out where the problem is, feel free
to ask more questions!
thanks
david jencks
>
> Dennis
>
>
>
> On 7/6/06, David Jencks <da...@yahoo.com> wrote:
>>
>> 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)
>>
>>
>
>
> --
> "It is impossible to design fool proof systems, because fools are
> so clever."
>
> Authour unknown
> --
>
> "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)
> <geronimo-service.xml>
Re: Re: Library Packaging for Geronimo 1.1
Posted by Dennis Cartier <de...@gmail.com>.
I have run into what I think may be classloader complications,
possibly the exact issue that you are alluding to below. After moving
some Acegi code into a CAR file that previously was included in the
WAR that uses it, upon deploy I get an error indicating a type
mismatch. This seems like it should not happen. The WAR file lists
Spring 1.2.8 as a dependency (Spring MVC code) and the CAR file lists
Spring 1.2.8 and Acegi 0.9.0 as its dependencies (as well as others).
I have tried shuffling around the required dependencies but have not
come up with a combination that is able to deploy without getting the
error (or other ones).
Any pointers on methods to deal with this appreciated.
Dennis
Error:
org.springframework.beans.TypeMismatchException: Failed to convert
property value of type [org.springframework.web.util.CookieGenerator]
to required type [org.springframework.web.util.CookieGenerator] for
property 'cookieGenerator'
On 7/7/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> So let's say you have a CAR file that loads Spring and some common
> code, and then a WAR file that adds the CAR as a dependency (= parent
> ClassLoader) and uses Spring MVC with classes packaged in the WAR.
> I'm not sure if this will work since Spring is loaded in the CAR
> ClassLoader and wouldn't be able to see the classes in the WAR
> ClassLoader. I find it hard to believe that there's not some way to
> get Spring to use the ThreadContextClassLoader instead of its own
> ClassLoader to load the beans defined in a Spring context, but I don't
> know how to do it.
>
> Do you think that's what you're running into?
>
> Thanks,
> Aaron
>
> On 7/7/06, Dennis Cartier <de...@gmail.com> wrote:
> > Thanks for the help David. Your response helped to get me on the right track.
> >
> > I was able to make your method 1b working, but was unable to get 1a
> > working. I get a NoClassFoundError upon deploying the WAR file during
> > the Spring context initialization. I tried deploying my package as
> > both a JAR file and as a CAR file (with appropriate dependency added
> > to the WAR) but neither seemed to get method 1a working.
> >
> > My geronimo-service.xml file is attached. I am wondering if I need
> > more in it as it seems pretty sparse. Some examples I found online had
> > GBean entries, but since I am only hostig class libraries, I could not
> > see the need.
> >
> > I can get by using method 1b but, 1a strikes me as being the more
> > efficient desirable method of operation, unless I am misunderstanding
> > what a CAR file represents.
> >
> > Dennis
> >
> >
> >
> > On 7/6/06, David Jencks <da...@yahoo.com> wrote:
> > >
> > > 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)
> > >
> > >
> >
> >
> > --
> > "It is impossible to design fool proof systems, because fools are so clever."
> >
> > Authour unknown
> > --
> >
> > "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)
> >
> >
> >
>
--
"It is impossible to design fool proof systems, because fools are so clever."
Authour unknown
--
"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)
Re: Re: Library Packaging for Geronimo 1.1
Posted by Dennis Cartier <de...@gmail.com>.
Thank-you David and Aaron. between the two of you, you gave me enough
hints to what I might be doing wrong.
As it turns out, I had made a poor choice of what to cleave out of my
monolithic WAR file as a first test. I had tried to separate my DAO
classes that needed Spring/OsCache as a dependency, but still had
Spring/OsCache in the WAR file rather than the repository. Once I
added the JARs to the repository and made the DAO module depend on
them, I was able to get method 1a working where I use a CAR file.
Thanks guys.
Dennis
On 7/7/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> So let's say you have a CAR file that loads Spring and some common
> code, and then a WAR file that adds the CAR as a dependency (= parent
> ClassLoader) and uses Spring MVC with classes packaged in the WAR.
> I'm not sure if this will work since Spring is loaded in the CAR
> ClassLoader and wouldn't be able to see the classes in the WAR
> ClassLoader. I find it hard to believe that there's not some way to
> get Spring to use the ThreadContextClassLoader instead of its own
> ClassLoader to load the beans defined in a Spring context, but I don't
> know how to do it.
>
> Do you think that's what you're running into?
>
> Thanks,
> Aaron
>
> On 7/7/06, Dennis Cartier <de...@gmail.com> wrote:
> > Thanks for the help David. Your response helped to get me on the right track.
> >
> > I was able to make your method 1b working, but was unable to get 1a
> > working. I get a NoClassFoundError upon deploying the WAR file during
> > the Spring context initialization. I tried deploying my package as
> > both a JAR file and as a CAR file (with appropriate dependency added
> > to the WAR) but neither seemed to get method 1a working.
> >
> > My geronimo-service.xml file is attached. I am wondering if I need
> > more in it as it seems pretty sparse. Some examples I found online had
> > GBean entries, but since I am only hostig class libraries, I could not
> > see the need.
> >
> > I can get by using method 1b but, 1a strikes me as being the more
> > efficient desirable method of operation, unless I am misunderstanding
> > what a CAR file represents.
> >
> > Dennis
> >
> >
> >
> > On 7/6/06, David Jencks <da...@yahoo.com> wrote:
> > >
> > > 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)
> > >
> > >
> >
> >
> > --
> > "It is impossible to design fool proof systems, because fools are so clever."
> >
> > Authour unknown
> > --
> >
> > "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)
> >
> >
> >
>
--
"It is impossible to design fool proof systems, because fools are so clever."
Authour unknown
--
"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)
Re: Re: Library Packaging for Geronimo 1.1
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
So let's say you have a CAR file that loads Spring and some common
code, and then a WAR file that adds the CAR as a dependency (= parent
ClassLoader) and uses Spring MVC with classes packaged in the WAR.
I'm not sure if this will work since Spring is loaded in the CAR
ClassLoader and wouldn't be able to see the classes in the WAR
ClassLoader. I find it hard to believe that there's not some way to
get Spring to use the ThreadContextClassLoader instead of its own
ClassLoader to load the beans defined in a Spring context, but I don't
know how to do it.
Do you think that's what you're running into?
Thanks,
Aaron
On 7/7/06, Dennis Cartier <de...@gmail.com> wrote:
> Thanks for the help David. Your response helped to get me on the right track.
>
> I was able to make your method 1b working, but was unable to get 1a
> working. I get a NoClassFoundError upon deploying the WAR file during
> the Spring context initialization. I tried deploying my package as
> both a JAR file and as a CAR file (with appropriate dependency added
> to the WAR) but neither seemed to get method 1a working.
>
> My geronimo-service.xml file is attached. I am wondering if I need
> more in it as it seems pretty sparse. Some examples I found online had
> GBean entries, but since I am only hostig class libraries, I could not
> see the need.
>
> I can get by using method 1b but, 1a strikes me as being the more
> efficient desirable method of operation, unless I am misunderstanding
> what a CAR file represents.
>
> Dennis
>
>
>
> On 7/6/06, David Jencks <da...@yahoo.com> wrote:
> >
> > 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)
> >
> >
>
>
> --
> "It is impossible to design fool proof systems, because fools are so clever."
>
> Authour unknown
> --
>
> "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)
>
>
>
Re: Library Packaging for Geronimo 1.1
Posted by Dennis Cartier <de...@gmail.com>.
Thanks for the help David. Your response helped to get me on the right track.
I was able to make your method 1b working, but was unable to get 1a
working. I get a NoClassFoundError upon deploying the WAR file during
the Spring context initialization. I tried deploying my package as
both a JAR file and as a CAR file (with appropriate dependency added
to the WAR) but neither seemed to get method 1a working.
My geronimo-service.xml file is attached. I am wondering if I need
more in it as it seems pretty sparse. Some examples I found online had
GBean entries, but since I am only hostig class libraries, I could not
see the need.
I can get by using method 1b but, 1a strikes me as being the more
efficient desirable method of operation, unless I am misunderstanding
what a CAR file represents.
Dennis
On 7/6/06, David Jencks <da...@yahoo.com> wrote:
>
> 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)
>
>
--
"It is impossible to design fool proof systems, because fools are so clever."
Authour unknown
--
"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)
Re: Library Packaging for Geronimo 1.1
Posted by David Jencks <da...@yahoo.com>.
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)