geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: geronimo plan help
Date Mon, 21 May 2007 16:53:37 GMT
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...


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

View raw message