Sounds like a plan.. it seems someone has already implemented all of these javabeans.
--- Aaron Mulder <[EMAIL PROTECTED]> wrote: > On Wed, 13 Aug 2003, Chris Opacki wrote: > > That's exactly it! My bad for not being a bit more > > verbose. The DConfig objects are actually > constructed > > from the DDBeans. Which makes me believe we want > to be > > using RMI if we load the DDBeans remotely. Maybe > we > > can try to more than one strategy to see what is > best. > > It does appear that there would be a 1 to 1 > > relationship between DDBean and the > > DConfigBeans...lots of stuff... > > Well, let me go on, then. Let's say we're > deploying an EJB "Foo" > with an EJB Reference to another EJB "Bar" (with the > reference named > ejb/Bar), and both are in the same EJB JAR, but > inexplicably don't use > an ejb-link. > > The tool side should provide a DDBeanRoot for > ejb-jar.xml in the > EJB JAR, with DDBeans for each EJB, for the EJB > Reference, and for other > tags in the ejb-jar.xml. (I just fat-fingered that > to jar-jar.xml and had > a horrible flashback, but that's a different story.) > > When the tool wants to configure this for Geronimo, > it gets a > DeploymentManager, and then says, more or less, > "dear deployment manager, > I have this nice EJB JAR represented by > [DDBeanRoot], please give me a > DConfigBeanRoot that represents the information your > product needs in > order to configure this EJB JAR." > > So Geronimo would prepare a DConfigBean tree that > has, let's say, > the root, a DConfigBean for each EJB, and a > DConfigBean for the EJB > reference. The DConfigBeans matching each EJB have > properties to set the > JNDI name. The DConfigBean matching the EJB > reference has a variety of > properties -- an option for the JNDI name to map the > EJB ref to, as well > as JNDI context configuration properties in case the > bean is in a > different server. > > Now, since presumably the user is working on all > this at the same > time in the tool, let's say they resolve the EJB > Reference from Foo to Bar > by configuring a JNDI name for Bar and then mapping > the reference to Bar's > JNDI name. But now they go back and change the EJB > name of Bar to Alice. > This would invalidate the DConfigBeans, which > presumably are holding > something like this under the covers: > > Foo -> JNDI name "myapp.Foo" > Bar -> JNDI name "myapp.Bar" > > So there's a mechanism for the DConfigBeans to > "listen for > changes" on particular DDBeans. Thus, when the user > changes the EJB name > of "Bar" to "Alice", the "Bar" DConfigBean gets > notified, rereads the > properties of the DDBean formerly known as "Bar", > and updates its internal > data model to something like: > > Foo -> JNDI name "myapp.Foo" > Alice -> JNDI name "myapp.Bar" > > And then the user can go and update the JNDI > setting for Alice in > the Alice DConfigBean screen. Or, the user can now > delete Alice > altogether, in which case the server side had better > delete its Alice > DConfigBean, so the DConfigBeanRoot contains only a > DConfigBean for Foo. > > So that's why the tool's DDBean implementation has > to be able to > fire XPathEvents for the DConfigBeans, and why > DConfigBeans want to > listen for events on specific XPaths. > > Also, all this work is going on in the JVM of the > tool. The tool > is directly invoking DConfigBeans which are present > in the tool's space. > If the DConfigBeans have to communicate with the > server, that's something > they handle under the covers, and it's all > irrelevant to the tool, which > just introspects the DConfigBeans that it's been > given. So the tool > doesn't need any RMI or anything. > > Make sense? > > Aaron > > > --- Aaron Mulder <[EMAIL PROTECTED]> > > wrote: > > > Oops -- upon looking at the spec, I think I've > been > > > the confused > > > one. Let me back up and try to lay this out, > and > > > then you tell me if you > > > agree. > > > > > > The goal of the spec is for a single tool to be > > > able to configure > > > and deploy applications to any server. So all > the > > > servers will provide a > > > common API, and all the tools will be coded > against > > > that API. However, a > > > fixed API can't represent all the configuration > > > information required by > > > all app servers, so JSR-88 provides base classes > and > > > then mandates that > > > the extensions to those base classes be > JavaBeans, > > > so they can be > > > introspected and configured at runtime. So the > > > server provides some > > > methods like "deploy" and a set of configuration > > > classes that can be used > > > by the tool to configure a specific app. The > tool > > > then creates and > > > packages an app, creates the standard J2EE DDs > for > > > it, invokes the server > > > implementation to edit server-specific > deployment > > > information for it, and > > > then invokes the server implementation to > actually > > > do the deployment, etc. > > > > > > Where I was confused is that the DDBeans > represent > > > the standard > > > J2EE deployment descriptor, as opposed to the > > > DConfigBeans, which > > > represent the server-specific deployment > > > information. Since the tool > > > packaged the xAR in the first place, it is > assumed > > > that the tool is > > > responsible for the standard J2EE DDs, so the > tool > > > provides the DDBean > > > objects. The server is responsible for the > > > DConfigBean objects, which > > > make use of the information in the DDBean > objects, > > > in order to configure > > > the server-specific information. > > > > > > So if you want to work on the DDBeans, you > really > > > *are* talking > > > about the tool implementation. The tool needs > to > > > implement the DDBeans, > > > and also present a user interface for the > arbitrary > > > JavaBean DConfigBeans. > > > The tool side doesn't need to worry about > > > communicating with the server > > > over the network -- it just grabs a > > > DeploymentManager locally, and it's > > > the responsibility of the server implementation > of > > > DeploymentManager and > > > the DConfigBeans to communicate with the server > as > > > appropriate (and when > > > in connected mode, etc.). > > > > > > Sound right to you? > > > > > > Aaron > > > > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
