Correct. We could propose the 'workaround' on the Wiki, even attaching an implementation in anticipation of the real solution.

Ok, I implemented the MBean approach and tested against 4.0.4.GA (Postgres as backend). I guess the only question I have is should we distribute this as a standalone service on the Wiki, check it in to the current GA branch, or wait until the next 4.x release.

I am inclined to use the Wiki at this point, not wanting to disrupt anything. W e can always roll it in a later 4.x release.

Of courrse, as we talked about, this is a simple workaround until the prefill can be implemented on the pool itself. I was going to look at doing this next.

Well Anil, thank you for that slick and generally malicous response :-). The idea basically being that 'if you are not an idiot...all should be well'.

I am willing to support it until I can deprecate it when the real prefill implementation is ready to roll. Eternity...judging by your response I will be lucky to last until the end of the week :-).

I was merely asking because there is no information on the Wiki regarding any sort of code freeze, halting dev procedures close to a release. A mere question of procedure gentlemen.

Bingo! Thanks boss.

I modified the standalone service to use the XSLT mechanism whereby the element in *-ds.xml kicks in the prefill behavior. A new template just generates the PoolFillerService MBean for now, this code is the same as before.

And I will say that it was a very elegant suggestion...it would seem to make deployment, management, migration much easier.

This is pretty much complete, and actually was implmented the 'right' way (ie no hack to use MBean to get DataSource etc, etc). However, a few things remain:

The XLST has been updated to include a element that gets set on the JBossManagedConnectionPool. However, as explained before, only certain SubPools can support the prefill mechanism. What will most likely happen is people will put the element in the *-ds.xml file, expect the pool to be filled and be surprised when it doesn't happen.

Best solution is to probably implement the prefill method on the other pools and print a warning saying, pool does not support etc, etc. Or, we can check the Criteria in the XSLT and force the attribute to false if things don't match.

Again, a bit of cleanup in order but I plan on closing this one down first thing in the morning.

I got greedy on this one and jumped ahead of myself. The primary issue is supporting the BySubject pool. Since ConfiguredLoginModule is the only type in which this is supported the tests in jca were failing that were using a DynamicLoginConfig (naturally). Prior to prefilling the pools, there is really no way, that I can determine, to test for the type of login module that would support this feature. I see two options:

1) Still allow for prefilling on Subject based pools, just document that it is only supported for a particular login module type.

2) Remove prefilling for Subject based pools and only allow prefilling on OnePool.

Answered my own question. I will document the login config modules that allow for this feature. All issues have been fixed and updated.