Hi Trustin,
Thanks for the quick response.
Yes, there's no immediate problem here for federation. I realise now
that there's no problem in having to gain access to the original
Configuration object when creating a new JNDI context each time. I can
simply create a new SyncConfiguration() each time.
Still, it does seem a little odd to have to create an empty
SyncConfiguration object each time and ensure it's in the environment
(or provides the environment). From the client's end it doesnt have
anything to do with the connection, unless I want to start the server up
or shut it down.
But it works. :)
Cheers,
Nick
Trustin Lee wrote:
Hi,
2005/6/21, Alex Karasulu <[EMAIL PROTECTED]>:
I understand that the configuration object can be gained from the
Spring context but how will a remote client access it? Surely the
client shouldn't have to know a thing about the configuration of the
server, so long as it fulfills the general contract of behaving as an
LDAP client? :) If I've misunderstood something, please let me know.
As Tony mentioned, configuration object is not related with remote
clients. You'll have to specify three mandatory JNDI properties:
SECURITY_PRINCIPAL
SECURITY_CREDENTIALS
SECURITY_AUTHENTICATION
If I remember correctly only the apacheds specific configuration
information has been put into the configuration object. The JNDI
information still has to be put in there I thought. If not we have an
issue because this will cause problems when using federation with the
provider.
Trustin was this the case?
I guess so. But it seems like AbstractContextFactory requires
Configuration object even if it is already started up and users just
want to get initial context. So I fixed it.
Trustin
--
ATLASSIAN - http://www.atlassian.com/
Confluence - the enterprise wiki - tried it yet?
http://www.atlassian.com/confluence/
--
