geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: More About JSR-88 and DConfigBeans
Date Wed, 29 Jun 2005 16:21:20 GMT
	Can't blame Eclipse for not using JSR-88 support.  We don't have
any yet to speak of, and it seems like few vendors do.  I'd like to
provide it, so that if people want to implement our stuff, they can use
JSR-88, and perhaps that will ease the way for other vendors to support it
better down the road.

	As for whether to develop the tool elsewhere, I think we
specifically need a JSR-88 tool to test our DConfigBeans with.  So I'm not
interested in joining this tool as is with an effort that plans to write 
custom screens and interfaces for each server.

	However, if the tool does eventually become a useful
general-purpose JSR-88 client, I'd be happy to transition it out of
Geronimo if people (on either side) think that's appropriate.

Aaron

On Wed, 29 Jun 2005, Jeremy Boynes wrote:
> Just a thought but these goals seem very similar to those for Eclipse 
> WTP - would it be worth combining the efforts?
> 
> AIUI WTP are currently defining proprietary bridges for each server - at 
> least when I asked about the current Geronimo integration they were not 
> using our JSR-88 support (and weren't for any other vendor either).
> 
> Doing the UI work at Eclipse would be useful for all J2EE servers and 
> you would have help developing the UI. We would still need to provide 
> all our own DCB implementations of course.
> 
> --
> Jeremy
> 
> Aaron Mulder wrote:
> > 	(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 sissonj@insession.com 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.
> > 
> > 
> > 	Sure.
> > 
> > Aaron
> 
> 

Mime
View raw message