You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Doug Lochart <dl...@capecomputing.com> on 2007/05/18 22:26:32 UTC

geronimo plan help

As I am struggling to deploy my app I have been scouring through the 
documentation looking for help and clues.  I keep running into examples 
that merely show what an openejb-jar.xml would look like or a sample 
geronimo-application.xml.  There amy be a few places but in most cases 
there is no explanation as to what all the elements in the xml mean and 
what they do.  More importantly there is no explanation as to how (if at 
all) the xml plans fit together within an ear.

These plans/xml docs are all part of the same ejb application (ear)

For example this is what I have with help from the forum.

<?xml version="1.0" encoding="UTF-8"?>
<application application-name="FrancePolicyServerEar"
              xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1"
              xmlns:sec="http://geronimo.apache.org/xml/ns/security-1.1"
              xmlns:sys="http://geronimo.apache.org/xml/ns/deployment-1.1">
  <sys:environment>
    <sys:moduleId>
      <sys:groupId>france</sys:groupId>
      <sys:artifactId>FrancePolicyServerEar</sys:artifactId>
      <sys:version>1.0</sys:version>
      <sys:type>car</sys:type>
    </sys:moduleId>
    <sys:dependencies>
      <sys:dependency>
      <sys:groupId>geronimo</sys:groupId>
      <sys:artifactId>axis</sys:artifactId>
      <sys:type>car</sys:type>
      </sys:dependency>
    </sys:dependencies>
    <sys:hidden-classes/>
    <sys:non-overridable-classes/>
  </sys:environment>
</application>

The sys:groupId etc may be self explanatory for some but I just made it 
up as I went along following what examples I saw but doing it blindly.  
Then I was told to put a dependency for axis in.  So I did it and I 
think it helped me get farther but what is it actually doing?  I mean if 
a forum user did not tell me how in the heck would I have known based on 
the documentation?

That brings me to my openejb-jar.xml.  Here the main namespace to use is 
dep where sys was used in the application plan.

openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1">
  <dep:environment 
xmlns:dep="http://geronimo.apache.org/xml/ns/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?

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?

Sorry if I am sounding cranky but I feel a little helpless.  I can 
usually crack open anything pretty quick and get things working but all 
this gbean stuff and extra config docs just don't seem to either make 
sense or is explained very well.  Is there someplace else I could look?  
Is there a geronimo book?

thanks for letting me vent

Doug


Re: geronimo plan help

Posted by David Jencks <da...@yahoo.com>.
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 "http://geronimo.apache.org/xml/ns/ 
>> 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 http://www.chariotsolutions.com/geronimo/.

>
> 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="http://www.openejb.org/xml/ns/openejb-jar-2.1">
>>>  <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/ 
>>> 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="http://geronimo.apache.org/xml/ns/deployment-1.1">"  
>> 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
>


Re: geronimo plan help

Posted by Sachin Patel <sp...@gmail.com>.
I don't know too much about the DConfigBean support but from a quick  
glance at the description one of the intents for DConfigBeans is to  
exploit its use through vendor tooling.  So regardless of what the  
underlying technology is being used to read/write the descriptor  
XMLBeans, EMF, or DConfigBeans, you should be able to create an  
Eclipse UI around any of the those.  There are certainly advantages  
and disadvantages to each and it could be that using DConigBeans is  
the best approach in the long run for both Geronimo and the Eclipse  
Plugin.  I wish I knew more about DConfigBeans and wether it can  
support things like in-memory writing of a plan and reverting  
changes, etc...

-sachin


On May 21, 2007, at 12:25 PM, David Jencks wrote:

> Can the eclipse plan editors be based on jsr-88 DConfigBeans?  We  
> certainly don't have complete DConfigBean support for our plans,  
> but having an actual editor using them might provide some incentive  
> to keep the jsr-88 support up to date and complete.  The more up to  
> date parts of the deployment wizards in the admin console use  
> DConfigBeans.
>
> I think there's supposed to be some kind of generic dconfigbean  
> based plan editor in NetBeans, but I've never tried it.
>
> thanks
> david jencks
>
> On May 21, 2007, at 6:04 AM, Sachin Patel wrote:
>
>> The primary issue is based on past experiences I chose EMF as the  
>> modeling framework around the plans, but after several releases  
>> came to the quick realization that it was too heavyweight for our  
>> purpose.  This and the fact that are schemas each release have not  
>> been cumulative additions and this makes it painful to provide UI  
>> support for every version of the schema.  Thus I've unfortunately  
>> considered this a dying effort.  What I would like to eventually  
>> do is simplify at least the use of EMF and just use the XMLBeans  
>> generated code and generate the editors out of it.  There is a  
>> good bit of migration work to do this, but in the long wrong it  
>> would simplify this greatly as well as reduce some footprint.
>>
>> The other option and one I like much better, is something we can  
>> do in addition but prior to rebuilding the editors is  to extend  
>> the XML structured text editor in WTP to build a custom deployment  
>> plan editor for eclipse that provides full dynamic content assist  
>> into our plans.  So though this won't provide a UI, it will  
>> provide a reliable XML editor that will correctly display element  
>> choices as you write your plans.  I think this would be much more  
>> valuable since it would provide 100% coverage and thus more used  
>> than the above and the maintainability would be a whole lot easier  
>> than maintaining a full set of form editors.
>>
>> -sachin
>>
>>
>> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>>
>>> Please read Aaron's book on Geronimo http:// 
>>> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
>>> page.html . I find it to be a great documentation for almost  
>>> anything related to Geronimo Deployment Plans.
>>>
>>> I can understand your frustrations. It's no different for me when  
>>> it comes to manually creating Geronimo Deployment Plans.
>>>
>>> I have always wished that Geronimo Development Tools (like  
>>> Geronimo Eclipse Plug-in) provide some facility for auto-creating/ 
>>> updating those deployment plans. I have created a wiki page  
>>> summarizing my proposal:  http://cwiki.apache.org/GMOxPMGT/ 
>>> geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
>>>
>>> Would be useful if you and other users/developers can provide  
>>> feedback on it as well post new proposals if any on that page. I  
>>> think it would be useful if I float a separate mail on User list  
>>> for this.
>>>
>>> - Shiva
>>>
>>> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
>>> > " http://geronimo.apache.org/xml/ns/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.
>>>
>>> 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.
>>>
>>> > Doug Lochart wrote:
>>> >
>>> >>
>>> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb- 
>>> jar-2.1 ">
>>> >>  <dep:environment
>>> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
>>> > 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
>>>
>>>
>>
>


Re: geronimo plan help

Posted by Sachin Patel <sp...@gmail.com>.
I don't know too much about the DConfigBean support but from a quick  
glance at the description one of the intents for DConfigBeans is to  
exploit its use through vendor tooling.  So regardless of what the  
underlying technology is being used to read/write the descriptor  
XMLBeans, EMF, or DConfigBeans, you should be able to create an  
Eclipse UI around any of the those.  There are certainly advantages  
and disadvantages to each and it could be that using DConigBeans is  
the best approach in the long run for both Geronimo and the Eclipse  
Plugin.  I wish I knew more about DConfigBeans and wether it can  
support things like in-memory writing of a plan and reverting  
changes, etc...

-sachin


On May 21, 2007, at 12:25 PM, David Jencks wrote:

> Can the eclipse plan editors be based on jsr-88 DConfigBeans?  We  
> certainly don't have complete DConfigBean support for our plans,  
> but having an actual editor using them might provide some incentive  
> to keep the jsr-88 support up to date and complete.  The more up to  
> date parts of the deployment wizards in the admin console use  
> DConfigBeans.
>
> I think there's supposed to be some kind of generic dconfigbean  
> based plan editor in NetBeans, but I've never tried it.
>
> thanks
> david jencks
>
> On May 21, 2007, at 6:04 AM, Sachin Patel wrote:
>
>> The primary issue is based on past experiences I chose EMF as the  
>> modeling framework around the plans, but after several releases  
>> came to the quick realization that it was too heavyweight for our  
>> purpose.  This and the fact that are schemas each release have not  
>> been cumulative additions and this makes it painful to provide UI  
>> support for every version of the schema.  Thus I've unfortunately  
>> considered this a dying effort.  What I would like to eventually  
>> do is simplify at least the use of EMF and just use the XMLBeans  
>> generated code and generate the editors out of it.  There is a  
>> good bit of migration work to do this, but in the long wrong it  
>> would simplify this greatly as well as reduce some footprint.
>>
>> The other option and one I like much better, is something we can  
>> do in addition but prior to rebuilding the editors is  to extend  
>> the XML structured text editor in WTP to build a custom deployment  
>> plan editor for eclipse that provides full dynamic content assist  
>> into our plans.  So though this won't provide a UI, it will  
>> provide a reliable XML editor that will correctly display element  
>> choices as you write your plans.  I think this would be much more  
>> valuable since it would provide 100% coverage and thus more used  
>> than the above and the maintainability would be a whole lot easier  
>> than maintaining a full set of form editors.
>>
>> -sachin
>>
>>
>> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>>
>>> Please read Aaron's book on Geronimo http:// 
>>> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
>>> page.html . I find it to be a great documentation for almost  
>>> anything related to Geronimo Deployment Plans.
>>>
>>> I can understand your frustrations. It's no different for me when  
>>> it comes to manually creating Geronimo Deployment Plans.
>>>
>>> I have always wished that Geronimo Development Tools (like  
>>> Geronimo Eclipse Plug-in) provide some facility for auto-creating/ 
>>> updating those deployment plans. I have created a wiki page  
>>> summarizing my proposal:  http://cwiki.apache.org/GMOxPMGT/ 
>>> geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
>>>
>>> Would be useful if you and other users/developers can provide  
>>> feedback on it as well post new proposals if any on that page. I  
>>> think it would be useful if I float a separate mail on User list  
>>> for this.
>>>
>>> - Shiva
>>>
>>> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
>>> > " http://geronimo.apache.org/xml/ns/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.
>>>
>>> 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.
>>>
>>> > Doug Lochart wrote:
>>> >
>>> >>
>>> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb- 
>>> jar-2.1 ">
>>> >>  <dep:environment
>>> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
>>> > 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
>>>
>>>
>>
>


Re: geronimo plan help

Posted by David Jencks <da...@yahoo.com>.
Can the eclipse plan editors be based on jsr-88 DConfigBeans?  We  
certainly don't have complete DConfigBean support for our plans, but  
having an actual editor using them might provide some incentive to  
keep the jsr-88 support up to date and complete.  The more up to date  
parts of the deployment wizards in the admin console use DConfigBeans.

I think there's supposed to be some kind of generic dconfigbean based  
plan editor in NetBeans, but I've never tried it.

thanks
david jencks

On May 21, 2007, at 6:04 AM, Sachin Patel wrote:

> The primary issue is based on past experiences I chose EMF as the  
> modeling framework around the plans, but after several releases  
> came to the quick realization that it was too heavyweight for our  
> purpose.  This and the fact that are schemas each release have not  
> been cumulative additions and this makes it painful to provide UI  
> support for every version of the schema.  Thus I've unfortunately  
> considered this a dying effort.  What I would like to eventually do  
> is simplify at least the use of EMF and just use the XMLBeans  
> generated code and generate the editors out of it.  There is a good  
> bit of migration work to do this, but in the long wrong it would  
> simplify this greatly as well as reduce some footprint.
>
> The other option and one I like much better, is something we can do  
> in addition but prior to rebuilding the editors is  to extend the  
> XML structured text editor in WTP to build a custom deployment plan  
> editor for eclipse that provides full dynamic content assist into  
> our plans.  So though this won't provide a UI, it will provide a  
> reliable XML editor that will correctly display element choices as  
> you write your plans.  I think this would be much more valuable  
> since it would provide 100% coverage and thus more used than the  
> above and the maintainability would be a whole lot easier than  
> maintaining a full set of form editors.
>
> -sachin
>
>
> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>
>> Please read Aaron's book on Geronimo http:// 
>> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
>> page.html . I find it to be a great documentation for almost  
>> anything related to Geronimo Deployment Plans.
>>
>> I can understand your frustrations. It's no different for me when  
>> it comes to manually creating Geronimo Deployment Plans.
>>
>> I have always wished that Geronimo Development Tools (like  
>> Geronimo Eclipse Plug-in) provide some facility for auto-creating/ 
>> updating those deployment plans. I have created a wiki page  
>> summarizing my proposal:  http://cwiki.apache.org/GMOxPMGT/ 
>> geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
>>
>> Would be useful if you and other users/developers can provide  
>> feedback on it as well post new proposals if any on that page. I  
>> think it would be useful if I float a separate mail on User list  
>> for this.
>>
>> - Shiva
>>
>> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
>> > " http://geronimo.apache.org/xml/ns/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.
>>
>> 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.
>>
>> > Doug Lochart wrote:
>> >
>> >>
>> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb- 
>> jar-2.1 ">
>> >>  <dep:environment
>> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
>> > 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
>>
>>
>


Re: geronimo plan help

Posted by David Jencks <da...@yahoo.com>.
Can the eclipse plan editors be based on jsr-88 DConfigBeans?  We  
certainly don't have complete DConfigBean support for our plans, but  
having an actual editor using them might provide some incentive to  
keep the jsr-88 support up to date and complete.  The more up to date  
parts of the deployment wizards in the admin console use DConfigBeans.

I think there's supposed to be some kind of generic dconfigbean based  
plan editor in NetBeans, but I've never tried it.

thanks
david jencks

On May 21, 2007, at 6:04 AM, Sachin Patel wrote:

> The primary issue is based on past experiences I chose EMF as the  
> modeling framework around the plans, but after several releases  
> came to the quick realization that it was too heavyweight for our  
> purpose.  This and the fact that are schemas each release have not  
> been cumulative additions and this makes it painful to provide UI  
> support for every version of the schema.  Thus I've unfortunately  
> considered this a dying effort.  What I would like to eventually do  
> is simplify at least the use of EMF and just use the XMLBeans  
> generated code and generate the editors out of it.  There is a good  
> bit of migration work to do this, but in the long wrong it would  
> simplify this greatly as well as reduce some footprint.
>
> The other option and one I like much better, is something we can do  
> in addition but prior to rebuilding the editors is  to extend the  
> XML structured text editor in WTP to build a custom deployment plan  
> editor for eclipse that provides full dynamic content assist into  
> our plans.  So though this won't provide a UI, it will provide a  
> reliable XML editor that will correctly display element choices as  
> you write your plans.  I think this would be much more valuable  
> since it would provide 100% coverage and thus more used than the  
> above and the maintainability would be a whole lot easier than  
> maintaining a full set of form editors.
>
> -sachin
>
>
> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>
>> Please read Aaron's book on Geronimo http:// 
>> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
>> page.html . I find it to be a great documentation for almost  
>> anything related to Geronimo Deployment Plans.
>>
>> I can understand your frustrations. It's no different for me when  
>> it comes to manually creating Geronimo Deployment Plans.
>>
>> I have always wished that Geronimo Development Tools (like  
>> Geronimo Eclipse Plug-in) provide some facility for auto-creating/ 
>> updating those deployment plans. I have created a wiki page  
>> summarizing my proposal:  http://cwiki.apache.org/GMOxPMGT/ 
>> geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
>>
>> Would be useful if you and other users/developers can provide  
>> feedback on it as well post new proposals if any on that page. I  
>> think it would be useful if I float a separate mail on User list  
>> for this.
>>
>> - Shiva
>>
>> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
>> > " http://geronimo.apache.org/xml/ns/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.
>>
>> 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.
>>
>> > Doug Lochart wrote:
>> >
>> >>
>> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb- 
>> jar-2.1 ">
>> >>  <dep:environment
>> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
>> > 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
>>
>>
>


Re: geronimo plan help

Posted by Shiva Kumar H R <sh...@gmail.com>.
Extending WTP's Structured Text Editors is definitely a workable solution.
My +1 for it ;-) They could later be extended to add form based editing.

Let's look more into JSR-88 DConfigBeans and see if Eclipse also provides
any generic DConfigBean based editors!

- Shiva

On 5/21/07, Sachin Patel <sp...@gmail.com> wrote:
>
> The primary issue is based on past experiences I chose EMF as the
> modeling framework around the plans, but after several releases came
> to the quick realization that it was too heavyweight for our
> purpose.  This and the fact that are schemas each release have not
> been cumulative additions and this makes it painful to provide UI
> support for every version of the schema.  Thus I've unfortunately
> considered this a dying effort.  What I would like to eventually do
> is simplify at least the use of EMF and just use the XMLBeans
> generated code and generate the editors out of it.  There is a good
> bit of migration work to do this, but in the long wrong it would
> simplify this greatly as well as reduce some footprint.
>
> The other option and one I like much better, is something we can do
> in addition but prior to rebuilding the editors is  to extend the XML
> structured text editor in WTP to build a custom deployment plan
> editor for eclipse that provides full dynamic content assist into our
> plans.  So though this won't provide a UI, it will provide a reliable
> XML editor that will correctly display element choices as you write
> your plans.  I think this would be much more valuable since it would
> provide 100% coverage and thus more used than the above and the
> maintainability would be a whole lot easier than maintaining a full
> set of form editors.
>
> -sachin
>
>
> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>
> > Please read Aaron's book on Geronimo http://
> > www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-
> > page.html . I find it to be a great documentation for almost
> > anything related to Geronimo Deployment Plans.
> >
> > I can understand your frustrations. It's no different for me when
> > it comes to manually creating Geronimo Deployment Plans.
> >
> > I have always wished that Geronimo Development Tools (like Geronimo
> > Eclipse Plug-in) provide some facility for auto-creating/updating
> > those deployment plans. I have created a wiki page summarizing my
> > proposal:  http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-
> > plans-how-to-simplify-creation-or-updation.html
> >
> > Would be useful if you and other users/developers can provide
> > feedback on it as well post new proposals if any on that page. I
> > think it would be useful if I float a separate mail on User list
> > for this.
> >
> > - Shiva
> >
> > On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
> > > " http://geronimo.apache.org/xml/ns/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.
> >
> > 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.
> >
> > > Doug Lochart wrote:
> > >
> > >>
> > >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1 ">
> > >>  <dep:environment
> > >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> > > 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
> >
> >
>
>

Re: geronimo plan help

Posted by Shiva Kumar H R <sh...@gmail.com>.
Extending WTP's Structured Text Editors is definitely a workable solution.
My +1 for it ;-) They could later be extended to add form based editing.

Let's look more into JSR-88 DConfigBeans and see if Eclipse also provides
any generic DConfigBean based editors!

- Shiva

On 5/21/07, Sachin Patel <sp...@gmail.com> wrote:
>
> The primary issue is based on past experiences I chose EMF as the
> modeling framework around the plans, but after several releases came
> to the quick realization that it was too heavyweight for our
> purpose.  This and the fact that are schemas each release have not
> been cumulative additions and this makes it painful to provide UI
> support for every version of the schema.  Thus I've unfortunately
> considered this a dying effort.  What I would like to eventually do
> is simplify at least the use of EMF and just use the XMLBeans
> generated code and generate the editors out of it.  There is a good
> bit of migration work to do this, but in the long wrong it would
> simplify this greatly as well as reduce some footprint.
>
> The other option and one I like much better, is something we can do
> in addition but prior to rebuilding the editors is  to extend the XML
> structured text editor in WTP to build a custom deployment plan
> editor for eclipse that provides full dynamic content assist into our
> plans.  So though this won't provide a UI, it will provide a reliable
> XML editor that will correctly display element choices as you write
> your plans.  I think this would be much more valuable since it would
> provide 100% coverage and thus more used than the above and the
> maintainability would be a whole lot easier than maintaining a full
> set of form editors.
>
> -sachin
>
>
> On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:
>
> > Please read Aaron's book on Geronimo http://
> > www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-
> > page.html . I find it to be a great documentation for almost
> > anything related to Geronimo Deployment Plans.
> >
> > I can understand your frustrations. It's no different for me when
> > it comes to manually creating Geronimo Deployment Plans.
> >
> > I have always wished that Geronimo Development Tools (like Geronimo
> > Eclipse Plug-in) provide some facility for auto-creating/updating
> > those deployment plans. I have created a wiki page summarizing my
> > proposal:  http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-
> > plans-how-to-simplify-creation-or-updation.html
> >
> > Would be useful if you and other users/developers can provide
> > feedback on it as well post new proposals if any on that page. I
> > think it would be useful if I float a separate mail on User list
> > for this.
> >
> > - Shiva
> >
> > On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
> > > " http://geronimo.apache.org/xml/ns/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.
> >
> > 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.
> >
> > > Doug Lochart wrote:
> > >
> > >>
> > >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1 ">
> > >>  <dep:environment
> > >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> > > 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
> >
> >
>
>

Re: geronimo plan help

Posted by Sachin Patel <sp...@gmail.com>.
The primary issue is based on past experiences I chose EMF as the  
modeling framework around the plans, but after several releases came  
to the quick realization that it was too heavyweight for our  
purpose.  This and the fact that are schemas each release have not  
been cumulative additions and this makes it painful to provide UI  
support for every version of the schema.  Thus I've unfortunately  
considered this a dying effort.  What I would like to eventually do  
is simplify at least the use of EMF and just use the XMLBeans  
generated code and generate the editors out of it.  There is a good  
bit of migration work to do this, but in the long wrong it would  
simplify this greatly as well as reduce some footprint.

The other option and one I like much better, is something we can do  
in addition but prior to rebuilding the editors is  to extend the XML  
structured text editor in WTP to build a custom deployment plan  
editor for eclipse that provides full dynamic content assist into our  
plans.  So though this won't provide a UI, it will provide a reliable  
XML editor that will correctly display element choices as you write  
your plans.  I think this would be much more valuable since it would  
provide 100% coverage and thus more used than the above and the  
maintainability would be a whole lot easier than maintaining a full  
set of form editors.

-sachin


On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:

> Please read Aaron's book on Geronimo http:// 
> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
> page.html . I find it to be a great documentation for almost  
> anything related to Geronimo Deployment Plans.
>
> I can understand your frustrations. It's no different for me when  
> it comes to manually creating Geronimo Deployment Plans.
>
> I have always wished that Geronimo Development Tools (like Geronimo  
> Eclipse Plug-in) provide some facility for auto-creating/updating  
> those deployment plans. I have created a wiki page summarizing my  
> proposal:  http://cwiki.apache.org/GMOxPMGT/geronimo-deployment- 
> plans-how-to-simplify-creation-or-updation.html
>
> Would be useful if you and other users/developers can provide  
> feedback on it as well post new proposals if any on that page. I  
> think it would be useful if I float a separate mail on User list  
> for this.
>
> - Shiva
>
> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
> > " http://geronimo.apache.org/xml/ns/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.
>
> 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.
>
> > Doug Lochart wrote:
> >
> >>
> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1 ">
> >>  <dep:environment
> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> > 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
>
>


Re: geronimo plan help

Posted by Shiva Kumar H R <sh...@gmail.com>.
An Architect user was suggesting on the other thread that a "tool/wizard for
auto creating Geronimo Deployment Plan by scanning the corresponding Java-EE
plan/annotation" would fit best within "Admin Console", may be as an
extension to the Deploy
New<http://localhost:8080/console/portal/apps/apps_all>tool. That way
Users won't be forced to start using Eclipse plug-in just for
the sake of creating Geronimo deployment plan :-)

- Shiva

On 5/22/07, Doug Lochart <dl...@capecomputing.com> wrote:
>
> Shiva Kumar H R wrote:
> > Please read Aaron's book on Geronimo
> >
> http://www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-page.html
> > <
> http://www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-page.html
> >.
> > I find it to be a great documentation for almost anything related to
> > Geronimo Deployment Plans.
> >
> Thanks.  I will give this a read tonight.
> > I can understand your frustrations. It's no different for me when it
> > comes to manually creating Geronimo Deployment Plans.
> >
> > I have always wished that Geronimo Development Tools (like Geronimo
> > Eclipse Plug-in) provide some facility for auto-creating/updating
> > those deployment plans. I have created a wiki page summarizing my
> > proposal:
> >
> http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
> > <
> http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
> >
> >
> > Would be useful if you and other users/developers can provide feedback
> > on it as well post new proposals if any on that page. I think it would
> > be useful if I float a separate mail on User list for this.
> >
> If I get to continue using Geronimo I will do my best.  I don't know if
> fancy Eclipse plug-in would be better as many of us don't use Eclipse
> and don't want to be forced into it.  To me just solid documentation and
> explanations as to what each piece means would suffice.  I hate blindly
> following and example and not knowing why something is the way it is.
>
> regards,
>
> Doug
> > - Shiva
> >
> > On 5/19/07, *Doug Lochart* < dlochart@capecomputing.com
> > <ma...@capecomputing.com>> 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
> >     > " http://geronimo.apache.org/xml/ns/deployment-{version}
> >     <http://geronimo.apache.org/xml/ns/deployment-%7Bversion%7D>".  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.
> >
> >     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.
> >
> >     > Doug Lochart wrote:
> >     >
> >     >>
> >     >> openejb-jar
> >     xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1
> >     <http://www.openejb.org/xml/ns/openejb-jar-2.1>">
> >     >>  <dep:environment
> >     >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> >     > 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
> >
> >
>
>

Re: geronimo plan help

Posted by Doug Lochart <dl...@capecomputing.com>.
Shiva Kumar H R wrote:
> Please read Aaron's book on Geronimo 
> http://www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-page.html 
> <http://www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-page.html>. 
> I find it to be a great documentation for almost anything related to 
> Geronimo Deployment Plans.
>
Thanks.  I will give this a read tonight.
> I can understand your frustrations. It's no different for me when it 
> comes to manually creating Geronimo Deployment Plans.
>
> I have always wished that Geronimo Development Tools (like Geronimo 
> Eclipse Plug-in) provide some facility for auto-creating/updating 
> those deployment plans. I have created a wiki page summarizing my 
> proposal:  
> http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html 
> <http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html>
>
> Would be useful if you and other users/developers can provide feedback 
> on it as well post new proposals if any on that page. I think it would 
> be useful if I float a separate mail on User list for this.
>
If I get to continue using Geronimo I will do my best.  I don't know if 
fancy Eclipse plug-in would be better as many of us don't use Eclipse 
and don't want to be forced into it.  To me just solid documentation and 
explanations as to what each piece means would suffice.  I hate blindly 
following and example and not knowing why something is the way it is.

regards,

Doug
> - Shiva
>
> On 5/19/07, *Doug Lochart* < dlochart@capecomputing.com 
> <ma...@capecomputing.com>> 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
>     > " http://geronimo.apache.org/xml/ns/deployment-{version}
>     <http://geronimo.apache.org/xml/ns/deployment-%7Bversion%7D>".  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.
>
>     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.
>
>     > Doug Lochart wrote:
>     >
>     >>
>     >> openejb-jar
>     xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1
>     <http://www.openejb.org/xml/ns/openejb-jar-2.1>">
>     >>  <dep:environment
>     >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
>     > 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
>
>


Re: geronimo plan help

Posted by Sachin Patel <sp...@gmail.com>.
The primary issue is based on past experiences I chose EMF as the  
modeling framework around the plans, but after several releases came  
to the quick realization that it was too heavyweight for our  
purpose.  This and the fact that are schemas each release have not  
been cumulative additions and this makes it painful to provide UI  
support for every version of the schema.  Thus I've unfortunately  
considered this a dying effort.  What I would like to eventually do  
is simplify at least the use of EMF and just use the XMLBeans  
generated code and generate the editors out of it.  There is a good  
bit of migration work to do this, but in the long wrong it would  
simplify this greatly as well as reduce some footprint.

The other option and one I like much better, is something we can do  
in addition but prior to rebuilding the editors is  to extend the XML  
structured text editor in WTP to build a custom deployment plan  
editor for eclipse that provides full dynamic content assist into our  
plans.  So though this won't provide a UI, it will provide a reliable  
XML editor that will correctly display element choices as you write  
your plans.  I think this would be much more valuable since it would  
provide 100% coverage and thus more used than the above and the  
maintainability would be a whole lot easier than maintaining a full  
set of form editors.

-sachin


On May 21, 2007, at 7:47 AM, Shiva Kumar H R wrote:

> Please read Aaron's book on Geronimo http:// 
> www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one- 
> page.html . I find it to be a great documentation for almost  
> anything related to Geronimo Deployment Plans.
>
> I can understand your frustrations. It's no different for me when  
> it comes to manually creating Geronimo Deployment Plans.
>
> I have always wished that Geronimo Development Tools (like Geronimo  
> Eclipse Plug-in) provide some facility for auto-creating/updating  
> those deployment plans. I have created a wiki page summarizing my  
> proposal:  http://cwiki.apache.org/GMOxPMGT/geronimo-deployment- 
> plans-how-to-simplify-creation-or-updation.html
>
> Would be useful if you and other users/developers can provide  
> feedback on it as well post new proposals if any on that page. I  
> think it would be useful if I float a separate mail on User list  
> for this.
>
> - Shiva
>
> On 5/19/07, Doug Lochart < dlochart@capecomputing.com> 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
> > " http://geronimo.apache.org/xml/ns/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.
>
> 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.
>
> > Doug Lochart wrote:
> >
> >>
> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1 ">
> >>  <dep:environment
> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> > 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
>
>


Re: geronimo plan help

Posted by Shiva Kumar H R <sh...@gmail.com>.
Please read Aaron's book on Geronimo
http://www.chariotsolutions.com/geronimo/geronimo-1.1/geronimo-html-one-page.html.
I find it to be a great documentation for almost anything related to
Geronimo Deployment Plans.

I can understand your frustrations. It's no different for me when it comes
to manually creating Geronimo Deployment Plans.

I have always wished that Geronimo Development Tools (like Geronimo Eclipse
Plug-in) provide some facility for auto-creating/updating those deployment
plans. I have created a wiki page summarizing my proposal:
http://cwiki.apache.org/GMOxPMGT/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html

Would be useful if you and other users/developers can provide feedback on it
as well post new proposals if any on that page. I think it would be useful
if I float a separate mail on User list for this.

- Shiva

On 5/19/07, Doug Lochart <dl...@capecomputing.com> 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
> > "http://geronimo.apache.org/xml/ns/deployment-{version}
> <http://geronimo.apache.org/xml/ns/deployment-%7Bversion%7D>".  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.
>
> 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.
>
> > Doug Lochart wrote:
> >
> >>
> >> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1">
> >>  <dep:environment
> >> xmlns:dep="http://geronimo.apache.org/xml/ns/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=" http://geronimo.apache.org/xml/ns/deployment-1.1">"
> > 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
>
>

Re: geronimo plan help

Posted by Doug Lochart <dl...@capecomputing.com>.
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 
> "http://geronimo.apache.org/xml/ns/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.

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.

> Doug Lochart wrote:
>
>>
>> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1">
>>  <dep:environment 
>> xmlns:dep="http://geronimo.apache.org/xml/ns/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="http://geronimo.apache.org/xml/ns/deployment-1.1">" 
> 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


Re: geronimo plan help

Posted by Lin Sun <li...@gmail.com>.
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 "http://geronimo.apache.org/xml/ns/deployment-{version}".  You 
'll want to look at the geronimo-application-{version}.xsd for 
geronimo-application.xml file.

Doug Lochart wrote:

> 
> openejb-jar xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1">
>  <dep:environment 
> xmlns:dep="http://geronimo.apache.org/xml/ns/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="http://geronimo.apache.org/xml/ns/deployment-1.1">" 
defined earlier.

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.

> 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.

HTH, Lin