[Jboss-dev-forums] [Design of Mail Services] - Re: Protocol Configuration Changes.

[<aco...@jb...>]

I'm so happy!  universalizing the deployment descriptor was a must (no fork of a dev vs non-dev).  Now the installation staying good is everyone's problem! :-)  Making sure we're easy to install is a passion of mine, mainly because of prior experience with other mail servers (especially the unix variety).  You know we'll be the first freaking configurable-by-humans IMAP that runs on Unix?  Seriously...gosh if you ever try and install any of the existing stuff...

Just a guess.  You should not use the "copy" task but instead copy within the build directory and then "move" it.  copy is not atomic, so the deployment scanner probably sees the directory but not the actual descriptor, decides its an empty directory and moves on.  Move is atomic within the same filesystem.  

So I am still not likely to be happy (will look at it probably monday but I understood where you were going by description) with it.  I think we need a bit of a change of direction on configuration.  As much as I like the mbean/microkernel approach -- we're well on our way to an XML-ization of sendmail.cf.  

I'm thinking of an abstract directory service.  Basically adding some extra lifecycle to the mbeans and they'll get their properties injected by said lifecycle manager.  This somewhat exists in the ServiceController built into jboss (start/stop/create/destroy) but I'm thinking a bit bigger.  

There is also the XMLAttributePersistenceService thingy, but its kind of semi-abandoned and less than blessed.  Its also not really appropriate for what we ultimately want to accomplish.

Mark each real property with a @configurable attribute of some kind.  The DirectoryService will contain all of the attributes in a tree like so:

domain
     mbean=foo
         description="Foo is that sticky goo on your shoo"
         depends(String[])={"jmx:name","jmx:name"}
         attributeName(only @configurable marked included)
                  depends="jmx:name"
                  description="A statement of truth"
                  dynamic=true
                  type=java.lang.String
                  value="izpack is better than cheese"

@configurable will take a parameter "dynamic" which will say whether the service must be restarted if it is changed.

The DirectoryService should be able to take different backing stores.  For instance Database.

Lastly it should be able to createServiceDescriptor(seachstring).  Thus if I say

DirectoryService.createServiceDescriptor("jboss.mail:*.*") I should get back a jboss-service.xml with all of the crap we need.  We can create this dynamically at startup and delete it at shutdown (or as a cleanup at startup).

Some of this may duplicate efforts in the microcontainer and friends (so we should research there and get feedback from that group).

DirectoryService.setAttribute(querystring, attribute, value) changes an attribute.

Eventually we'll have:  ClusteredDirectoryService which will handle notifications via distributed state.

A "MailServiceLauncherMBean dependant on the DS" should call "DirectoryService.createDeploymentDescriptor("jboss.mail:*.*",url) and MainDeployer.deploy(url)" upon its startup.  This can actually handle everything including hibernate-service.xml i think.

But you ask "what about installation"?

DirectoryService.loadDescriptor(url) should take a jboss-service.xml and load it to the underlying backing storage.

why?

So one of JBoss's biggest weaknesses is that it's dynamic management requires you to go to that epitomy of UI design http://localhost:8080/jmx-console.  Unfortunately it isn't really a cluster thing and it doesn't persist anything.  Thus its useless for our needs.

Also XML hell sucks.  We need a way to clusterwide configure, manage, hot change.  Including wiring.  This is support for the installer, the needed gui admin tool.

I suspect the GUI admin tool can work with the same overall framework as the webmail if we go the laszlo route.

-Andy

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3888767#3888767

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3888767