> 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?
Yes this will work for us. But if you place this in security/core your code will need to depend on this module. If that is not a problem for you then lets put it there.
regards,
kumar
>
> >>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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>