V B Kumar Jayanti wrote on 07/20/10 12:59 AM:
> Hi Bill,
>
>
> The code looks fine to me. The null check for file property is not necessary
> since this is a compulsary property for a file realm and is enforced by both
> CLI and GUI (but it us probably safe to leave it to cater to
> hand-modification of domain.xml). We are currently writing a similar method
> for Embedded EJB Mode where we need to copy these keyfiles to the designated
> Embedded Temp Directory. So if you are placing this method in some common
> place we can call it as well.
I hadn't planned to, but if you want to suggest a place to put it I can
do that. Currently the code doesn't actually depend on the FileRealm
class (which would be a natural place to put it), and in fact the module
that the code is in doesn't depend on the module that contains the
FileRealm class, but I suppose it could.
Perhaps I should just add something like this to FileRealm:
public static List<String> getRealmFileNames(Config config)
This would just return the values of all the "file" properties from
all the file realms. Would that serve your needs as well?
>> One of the things the startup synchronization code needs to do is to
>> synchronize all the files for file realms used by an instance.
>
> So do we document that keyfiles not residing in the config are not managed by
> clustering infrastructure and developers have to take care of synchronizing
> them on their own.
We will have to document that, yes.
In general, nothing outside of the domain directory is managed.
The config directory is the obvious place under the domain directory
to put such files. I could handle such files anywhere under the
domain directory, but it's more work and I don't think it's worth it.