(3:59:29 PM) Marcus: stefan and I were discussing our options in the kerberos case and we came up with 3 options... do you have time now to talk about it?
(3:59:35 PM) anil_msn: k
(4:00:10 PM) Marcus: option 1 is to remove the debug message (undo the jira issue)
(4:01:20 PM) Marcus: option 2 is to assume only jboss login modules will have that option, so we filter the login modules by the class name and only add the option to the map if the package is org.jboss.security
(4:03:13 PM) Marcus: option 3 we modify the security_config.xsd to add an attribute to the <login-module> element to specify if the login module accepts the debug option. this attribute will not be required and defaults to true. in a rare case like this, the costumer can set this attribute to false so that the option will not be added to the map
(4:05:15 PM) anil_msn: I was thinking about option 2 in the afternoon
(4:05:38 PM) anil_msn: but I think we need option 3 because customers who have written their own login module can get the sec domain
(4:08:18 PM) Marcus: option 3 is probably the best in our opinion. everything keeps working as it is and only in the rare occasion where a custom login module has this problem we have a workaround
(4:09:45 PM) Marcus: with option 2, custom login modules that extend one of our own will print null for the config name, because the option will not be in the map

When Marcus and I discussed this issue earlier today, we first considered adding some kind of check (for example, to make sure the login module is not the IBM Kerberos LM) in the AuthenticationInfo class before setting the security-domain name option, to avoid this kind of problem. This approach has a clear downside: if later on we find out about another login module that doesn't accept extra options, we will have to change our check and the code will have to be re-compiled.

Thus, I think the approach Marcus is suggesting is better, as it will allow users to specify that they don't want security domain name to be automatically inserted as a module option in the configuration file. This way, no code has to re-compiled or changed.

This is basically a workaround to deal with morons while writing login modules get choked with additional module options (that they do not know about).

You are given a map of options. Just take the ones you want and ignore the rest. Why is that difficult?

I think a bug report should be filed with the IBM JDK.

Marcus, let me take a look at how the module option semantics were weaved into get into all login modules before you proceed.

We can also use a system property which turns of this module option being added to login modules. This is the simplistic approach.

UPDATE: This issue has been fixed via a system property (that will disable the addition of the security domain via the module option).

What is the system property and what to set to? I am currently migrating our EJB2 based app from JBoss 4.0.3SP1 to 5.0.1.

Appreciate your helping me out here.