[ https://issues.jboss.org/browse/JBWEB-228?page=com.atlassian.jira.plugin.... ] karin k commented on JBWEB-228: ------------------------------- This would not solve the requirement of making the authenticator globally available (and manageable by means of DMR). Our approach is to install JBoss runtimes in a most suitable way for our customers and take the burden from them to know the insights of JBoss in details. Formerly with JBoss 4.2.3 we have enhanced JBoss Web to know our Authenticator (in some intrusive way). Afterwards enabling the Authenticator was just using it in the auth-method (which was easy and handy). Using your proposed approach would mean that the developer or application deployer has to know how configure the valve, where to get the classes from. From my point of view this sounds tricky and not easy at all. You might say that we could still enhance JBoss Web as we did before. This is correct. But our intent is to switch from the Community Version towards the EAP version. And I'm not sure if we are allowed to do such hacks in the EAP version. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBWEB-228?page=com.atlassian.jira.plugin.... ] karin k commented on JBWEB-228: ------------------------------- OK. I think I see your point. To summarize: your proposal would be to implement a JBoss AS 7 extension (subsystem) for loading the authenticator valve and adding it to the valve chain. Right? I personally think this is much better than configuring it per app in the jboss-web.xml file (because it would not need an additional configuration on application developer/deployer side, besides application developer/deployers don't have to care where to get the classes from). IMO I still think this approach would have 2 drawbacks (when comparing it with the possibility of the registration of the Authenticator in the file Authenticator.properties file): * Developer/Deployer cannot configure the Authenticator by means of web.xml. It's even not possible to see by means of the web.xml file which Authenticator is really in use. As far as I know if a custom Authenticator is configured as a valve, JBoss will always take the valve configuration and will ignore the configuration in the web.xml file. This could be tricky (somehow magic) in terms of support and maintenance * The valve cannot be enabled/disabled by means of a deployment. It will be either always enabled or disabled (if we control this by means of a system property). For instance it is not possible to have 2 different War files deployed in one JBoss where one needs my custom Authenticator and the other one needs a Java EE Standard Authenticator. -> Using the jboss-web.xml approach per deployment this requirement can be solved (coming along with the drawback of a more tricky configuration (and class loading). I don't understand why JBoss cannot just provide the possibility to plugin custom authenticators and the required configuration for them (including the mapping to a auth-method usable in the web.xml file) in the standard subsystem web. To detail the requirement - The authenticator should be made available globally (just like the standard Java EE Authenticators are made available by the container) - The authenticator should be configurable / enabled per deployment (the same way like it is for a standard Java EE Authenticator) - And best would be that the configuration mechanism in use is the same than it would be for Java EE standard authenticators (using a custom auth-method in the web.xml file) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira