geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: geronimo plan help
Date Sat, 19 May 2007 15:42:30 GMT

On May 19, 2007, at 7:07 AM, Doug Lochart wrote:

> Lin,
> Thanks for trying to help.  I do appreciate it.  I may not have  
> made my questions/gripes clear.  So I will reiterate after your  
> replies.
> Lin Sun wrote:
>> Hi, I am not a plan expert at all but I'll try answer your  
>> questions...
>> What I find most useful besides reading the existing samples and  
>> documentations, is to use the schema files (generally located at  
>> the server_home\schema directory.)  For example, I am looking at  
>> my geronimo 2.0 server now, and the geronimo-module-{version}.xsd  
>> is the schema for namespace " 
>> deployment-{version}".  You 'll want to look at the geronimo- 
>> application-{version}.xsd for geronimo-application.xml file.
> I have looked at the examples and what I have now is from them as  
> well as help from the forum.  What I am griping about is that even  
> the documents are syntactically described in the xsd they are not  
> described verbally as to what they mean or how they are used.  I  
> can read and use a schema but it doesn't help if I don;t know how  
> or why I am constructing the xml document.

I tend not to look at geronimo documentation so there may be a lot  
more documentation avaliable (such as on the web site) and this is by  
no means up to date on details but I hope you are aware of Aaron's  
book available from

> The other issue I had was that I have an EAR with a WAR and EJB-JAR  
> inside.  Nowhere in the documentation did it cover the rules of  
> what plans are required.  Almost all examples attacke either a WAR  
> or EJB alone.  The one example that starts doing an EAR is never  
> completed.
> So when I was creating mine I had a geronimo-application.xml (which  
> I kept outside the ear), a geronimo-web.xml in the WAR, and an  
> openejb-jar.xml in the ejb.jar.  One forum member asked me to  
> remove the geronimo-web.  It seemed to not break anything and I  
> think it may have made things go farther but again I still have no  
> clue what combinations (or why) of geronimo specific plans are  
> required in an ear.

I think I suggested removing the war, not just the war plan.

We try to provide flexibility in how you supply the plan and try to  
make it so plans are not needed.  There's a schema for each kind of  
module plan (rar, app client, ejb, generic web, jetty, tomcat).  You  
can  always put these in the module itself in which case you have to  
name them appropriately (such as geronimo-ra.xml, geronimo-web.xml).   
Alternatively for an ear you can include  these "sub plans" in a  
unified ear plan.  If you do this you can include the unified plan in  
the ear, calling it geronimo-application.xml, or you can supply it as  
an external file to the deployer.

All plans (including the ear plan) start with an environment element  
that describes the classloader for the component.  This is somewhat  
misleading for rar and ejb modules in an ear since the information in  
the module environment element is merged into the ear environment to  
create a single classloader description.  Anyway you specify a name  
(moduleId), dependencies (which are either parents of the classloader  
or jars included in the classloader) and some details such as whether  
the classloader is parent-first or child-first, and exceptions to the  
parent/child first rule (hidden-classes and non-overridable-classes).

The moduleId for modules in an ear is useful for app clients and web  
apps but is pretty much ignored IIRC for ejb and rar modules in an  
ear.  For a standalone module it is always important.

After the environment element there is module specific xml that is  
hopefully comprehensible from the schemas.

Geronimo stores its dependencies in a maven-repo like layout, and we  
refer to them using a maven-like syntax.  So, just like in a pom you  
have groupId to specify the organization producing the artifact,  
artifactId to specify the particular artifact, type to specify the  
type of the artifact, and version to specify the version of the  
artifact.  I don't think its advisable to end a groupId with a ., it  
may end up with hard-to-interpret directory paths like  
qdfrancepolicy//FrancePolicyServverEjb.  On the other hand since IIUC  
this ejb jar is in an ear the moduleId is ignored.

Hope this helps a bit

david jencks

>> Doug Lochart wrote:
>>> openejb-jar xmlns="">
>>>  <dep:environment xmlns:dep=" 
>>> deployment-1.1">
>>>    <dep:moduleId>
>>>      <dep:groupId>qdfrancepolicy.</dep:groupId>
>>>      <dep:artifactId>FrancePolicyServverEjb</dep:artifactId>
>>>      <dep:version>1.0</dep:version>
>>>      <dep:type>car</dep:type>
>>>    </dep:moduleId>
>>>    <dep:dependencies>
>>>      <dep:dependency>
>>>        <dep:groupId>geronimo</dep:groupId>
>>>        <dep:artifactId>tomcat</dep:artifactId>
>>>        <dep:type>car</dep:type>
>>>      </dep:dependency>
>>>    </dep:dependencies>
>>>    <dep:hidden-classes/>
>>>    <dep:non-overridable-classes/>
>>>  </dep:environment>
>>>  <enterprise-beans>
>>>    <session>
>>>      <ejb-name>FrancePolicyServer</ejb-name>
>>>      <jndi-name>qdfrancepolicy.FrancePolicyHome</jndi-name>
>>>    </session>
>>>  </enterprise-beans>
>>> </openejb-jar>
>>> Is the dep:groupId supposed to match the sys:groupID on the app?   
>>> If not how is it used?  What does artifactid do?  Does it matter  
>>> what I name it?  Does the name have to correspond to another  
>>> field somewhere?
>> No, it needs to be dep:groupId here as you had "<dep:environment
>> > xmlns:dep="">"  
>> defined earlier.
> This I got from an example but I still would like an explanation of  
> what it means.  To me it looks I just use the package of the bean  
> as that is what the example had (with a trailing dot) but no  
> mention is made as what, how or why.
>> An artifactid is the artifact/module's unique id inside of the  
>> repository (typical location is server_home\repository).   You  
>> need to come up with a unique id for your module.   This is  
>> actually a maven concept.
> Okay, this is what I thought so when I have an EAR with an EJB and  
> WAR what do I have?
> 1 module (the application) with 2 or 3 artifiacts unique within the  
> module but not necessarily unique to all of the server OR
> 3 moules one for the ear, war, and ejb and they need to be unique  
> globally?  Again this is the stuff that is missing a good narrative  
> in my opinion.
> I would like to write up something covering all this stuff as I  
> feel I am not the only one in this boat.  However I cannot write  
> about what I do not grasp fully.
>>> Then there is the dep:dependency.  I added geronimo/tomcat in  
>>> because I was asked to do so (thanks again by the way).  I assume  
>>> it is telling geronimo that I want to use tomcat as my web  
>>> container but again I can't find any decent explanation as to  
>>> what is going on.  The IoC design of this thing is real cool but  
>>> unless I am just totally stupid ( I am green with EJB ) I cannot  
>>> seem to find anything that pieces things together in any coherent  
>>> fashion.
>>> Am I missing something?  Did all of you pop in and look at the  
>>> plan docs and just suddenly realize how to do it in a day or  
>>> something?
>> By specifying the dependencies, your app asks the server to make  
>> sure all the dependency modules are avail when your app starts.
> I _understand_ what a dependency means _BUT_ I could not find  
> anything that specified what modules you need, what are supplied as  
> default, and how you would know if you need them.  There are a lot  
> of things in the repository after you install geronimo.  It looks  
> like all of geronimo is a bunch of modules working together (great  
> concept, I like the Spring methodology) but to me as a newbie I  
> think they are just part of geronimo and that I do not need to mess  
> with anything in there.
>> HTH, Lin
> Thanks Lin, I hope others can also jump in a get a good discussion  
> going.  Maybe I will get enough info and work my way through my  
> problems to actually write up a good overview.
> Doug

View raw message