geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject More About JSR-88 and DConfigBeans
Date Wed, 29 Jun 2005 15:57:08 GMT
	(Prefix: note that JSR-88 applies only to J2EE module
configuration -- WARs and EJB JARs and so on -- not server configuration
like ports and the admin account and which web container to run.)

On Wed, 29 Jun 2005 wrote:
> Your approach is probably fine for a testing tool.  I would like to be 
> able to have a look/play with the tool to get a better feel for how it is 
> used and its level of usability.  I am wondering whether in the long term, 
> specific GUI code will need to be written for the more complex parts of 
> the configuration (e.g. security configuration) to make to user friendly. 

	For a pure JSR-88 tool, it is not possible to customize the GUI 
for server-specific information.  All you can do is build a GUI 
appropriate to the JavaBeans (and DConfigBeans) supplied by the server 
vendor, so you're limited by what they choose to provide in their 
BeanInfo, etc.  We do need a tool like this to use while developing 
DConfigBeans on order to get an idea of whether our BeanInfo is 
adequate. :)

	Of course, we can write a configuration tool that does not conform 
to jsr-88 as well, and provides a fully customized GUI for everything.  
I'm not sure how useful that is as a standalone tool -- I'd assume that 
we'd do better to provide IDE plugins that do the same.

> I was also wondering (long term again) whether during installation some 
> configuration tasks may be more suited to different GUI approaches (e.g. a 
> wizard or a graphical display showing relationships between 
> objects/servers etc).

	This would be interesting for J2EE module configuration as well.  
Note that we could, for example, provide a "configure your EJB JAR"
wizard, which took you step by step through all the elements of the
ejb-jar.xml, and happened to let you configure server-specific information
for the EJBs as you go.  But the server-specific part would be a little
generic.  Such as, when working on a CMP entity bean, Geronimo lets you
configure an automatic primary key generator (DB sequence or whatever).  
We wouldn't necessarily be able to say "next, decide whether you want the
database to automatically provide primary keys for your entity bean" --
because via JSR-88, we don't really know which server-specific settings
are which, only that there are some.  On the other hand, the Geronimo
automatic key generation properties could be encapsulated in a JavaBean
with a BeanInfo that includes a shortDescription saying "These settings
allow you to configure automatic key generation for an EJB, for cases
where the database can supply the IDs for new beans (such as with a
database sequence or auto_increment column".  Then our tool can pop up a
screen that edits that JavaBean, with that description on the screen.  So
this is why it's important to have high-quality BeanInfo and stuff -- so
we don't just have a screen full of 10 fields with cryptic names.

> It would be good to have some more discussions on 
> what is required for installation and configuration and how you see that 
> working from a user perspective.  Do you think that information would need 
> to be displayed differently when the user is installing as opposed to 
> modifying settings?

	Well, again, this tool only helps you write your deployment
information for a J2EE module -- web.xml and ejb-jar.xml and the Geronimo
openejb-jar.xml and geronimo-jetty.xml and so on.  It does not let you
configure the server, by changing the port for the web container, or
enabling SSL, or changing the admin username, etc.  That needs to be a 
separate discussion.

> >    Also, at the end of the day, I think the tool should have a fixed 
> > editor GUI for each J2EE descriptor, and only be dynamic for the 
> > DConfigBeans.  Being fully dynamic is not really as usable, it seems.
> What happens with the JavaBeans (e.g. for the security info) that you 
> mention in the "DConfigBeans Starter Info" email.

	This would be another example of what I was trying to describe 
above.  While editing an ejb-jar.xml, you'd have a few server-specific 
screens or options after the standard ones.  So, something like:

1) Define EJBs (ejb-jar.xml enterprise-beans)
2) CMP Relationships (ejb-jar.xml relationships)
3) Security Roles (ejb-jar.xml assembly-descriptor)
4) Container-Managed Transaction (ejb-jar.xml assembly-descriptor)
5) Messaging Destinations (ejb-jar.xml assembly-descriptor)
6) "Add Common Libraries to ClassPath" (openejb-jar.xml dependency)
7) "Geronimo Security Settings" (openejb-jar.xml security)
8) "Add Module-Scoped Geronimo Services" (openejb-jar.xml gbean)

So the first few entries are straight from ejb-jar.xml, and may have 
Geronimo information mixed in (the example above included Geronimo 
settings within the "Define EJBs" section).

The last few entries are Geronimo things that have no counterpart in
ejb-jar.xml.  We can probably put a nice name on them like above, if they
have appropriate BeanInfo.  But the screens themselves must be built
dynamically, based on the fields and properties in the beans.

> Look forward to getting more familiar with the configuration code, as I 
> think configuration is an area we really need to work out.
> Thanks for the writeup on DConfigBeans.



View raw message