The MBean is a workaround.
Only the pool knows internally whether prefilling makes sense.
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.
You can always create a testcase in the 4.x testsuite that validates that inclusion in 4.0.4.GA will not break anything.
If that happens, then I do not think there is any issue in including in GA. Right?
The decision should be based on whether you are willing to support it
from now to eternity (assuming the proper solution will be implemented later)
1) If you don't want to support it, put it on the WIKI as an example.
2) If you do want to support it, put it in cvs and add doco on how to use it
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.
The rules are simple. ;-)
Supported(able) code remains in the codebase.
I am not a big fan of people that dump features in the codebase
and then don't support it.
On deprecation, I am also not a big fan of lots of cruft for
"backwards compatibility" reasons. But I am even less of fan
of breaking working user configurations.
I don't mind breaking user configurations when the underlying feature
doesn't work in the first place. :-)
I prefer it when the user facing part doesn't change.
e.g. You could add your mbean to the xslt when they use
That way they won't even notice when the better solution comes along.
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.
The WARNing is the best option. No silent failures!
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.