Protocol Configuration Changes.

[mikezzz]

Hi,

I have completed (but not commited) some changes to remove the SMTPProcotocol/POPProtocol.setProperties() and replace it with standard MBean attributes for each property. I have held off committing right now as the change is bigish. Also Andy will probably want to hit me as it will mean changes to his Velocity templates for izPack. However I have made the necessary updates to the default jboss-service.xml and the unit tests also pass. The getProperty/getPropertyBool/getPropertyLong methods still exist and are still used, but instead they read the properties using MBeanServer.getAttribute. The SMTPConstants also changed to use MBean property names.

However I would like to get these changes in. The reasons for the change are:

- More type safe.
- Makes it easier to change individual properties from code. This is useful for testing where tests use different properties, only have to set the necessary ones and not supply a full configuration for each test (Unit tests for JBMAIL-16 really would like this).
- Removes a total of ~200 lines of code from SMTPProtocol/POPProtocol.
- Makes it easier to manage individual properties for the Protocols via JMX-Console.

If there are no serious objections, I will commit this in the next couple of days.

Mike.

P.S. Andy I am happy to help out fixing the templates if required.

[acoliver]

Please wait until I merge izPack stuff in. my build changes make the old jboss-service.xml file irrelevant!

Don't worry, I'll get you back. I want to do away with half of the idea of the jboss-service.xml overall anyhow.. :-P

[mikezzz]

I have committed this change now, merged in with the new velocity templates for the IzPack installer. I have also merged in the test suite stuff as well (they pass).

One weirdness I have found is that if I deploy the mail-test.sar exploded within JBoss doesn't pick it up. I have set it up to deploy the mail-test.sar seperately as jar which works. Not a problem, but strange though.

Mike.

[acoliver]

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

[acoliver]

Anyhow thats just one idea of how to do it? Am I way off? What do you guys think? Is there an easier "third way"?

[mikezzz]

The stuff you mention looks interesting. I wonder it there is a way we could hook this into the MBean Server as well, perhaps with notifications. Such that if someone did MBeanServer.setAttribute(beanName, attribute, value) we could receive an event that would allow the Directory Store to be updated.

I agree with the idea that there needs more that just some XML files for deployment. I know our CM team at work tend to get frustrated by some of the obsure locations for some configuration options. To a JBoss-fluent developer it make sense, but administrators tend to find it confusing (and admins are probably our target audience for JBMail).

My changes were mostly mundune, mainly around making all simple properties configurable as MBean attributes, rather than parsing our own XML structure. Mostly for consistency and my preferred programming technique involves the 'delete' key.

Mike

[acoliver]

My thought was not to do this via the MBeanServer for various reasons, instead do it via an aspect on the actual attribute method itself. Reason being that I'm only interested in "@Configurable" notifications. Yes I can do that with a filter and all that jazz but it seems cleaner to me for some reason.

Yes, your changes make sense. I had a good reason for the way I did it at the time... That reason escapes me and is probably crap. Whatever it was was certainly far less important than ease of use.