Rickard �berg wrote:
R�> Hi!
R�> Oleg Nitz wrote:
>> R�> On second thought, no I don't understand what you're doing with JNDI.
>> R�> First you are binding the JSMS to "jaas" and then you are creating a new
>> R�> subcontext "jaas.sm" parallel to "jaas" in the root context (i.e. in the
>> R�> root of JNDI you will have a "jaas" binding and a subcontext called
>> R�> "jaas.sm".
>> Correct.
R�> Is there a reason why there is not instead a "jaas" context with a "sm"
R�> subcontext, containing all SM's?
But SMS is bound to "jaas", therefore jaas" cannot be Context at the
same time.
>> R�> Why do you have a "." in the name BTW?) ,
>> Why not?
R�> Because it is somewhat confusing as it seems you really wanted a "sm"
R�> subcontext to a "jaas" context.
Oh, I really want, but I can't :-(
>> R�> and then on lookup you bind new JSM's into the "jaas.sm"
>> R�> subcontext. Why? First of all, can there be many JSM's?
>> R�> And should they really be created on the fly as you
>> R�> do now if they're not already created when the lookup is done? And why
>> R�> don't you simply use a hashtable where you store the JSM's instead of
>> R�> the "jaas.sm" subcontext?
>>
>> R�> Can you please explain what you want to do with this code.
>> Okay, I'll try.
>> auth.conf may contain multiple "application entries".
>> They correspond to different SecurityManagers and/or RealmMappings,
>> different beans may refer to different "application entries".
>> For each application entry in auth.conf, say "MySecurity", I want to
>> create new JSM("MySecurity") and to bind it to JNDI name
>> "jaas/SecurityView". But JAAS doesn't give a possibility to get
>> the list of all application entry names, and this operation actually
>> doesn't make sense, because auth.conf contains the default "other"
>> entry, so that if "MySecurity" is not found in auth.conf, "other"
>> should be silently used. Therefore, I cannot statically bind security
>> managers on JSMS startup, but I have to bind them during
>> deployment, when the correspondent JNDI lookup is being performed.
>> I am no expert in JDNI, so I have implemented the only solution of
>> this problem that I have found: JSMS is bound to "jaas" JNDI
>> name, and returns Context, to which JSM is lazily added.
>> If you tell me how can this be implemented in some easier way,
>> I shall follow your recommendations ASAP.
R�> Yes, I see now. Basically you want a "jaas" context with a bunch of
R�> JSM's in it, right?
Right.
R�> So, basically you could change the JSMS object
R�> factory to lookup JSM's from a hashtable based on the rest of the name
R�> (i.e. almost as you do now). If no JSM is found, then put a new one into
R�> the hashtable.
R�> Makes sense?
Yes, I tried this variant first. But JNP expects that I return
Context, in which JNP performs the second lookup for the rest of the
name. See NamingContext.lookup(Name):
...
else if (res instanceof ResolveResult)
{
// Dereference partial result
try
{
Object resolveRes = ((ResolveResult)res).getResolvedObj();
if (resolveRes instanceof LinkRef)
{
...
} else
{
try
{
Context ctx = (Context)NamingManager.getObjectInstance(resolveRes,
getAbsoluteName(name),
this,
env);
return ctx.lookup(((ResolveResult)res).getRemainingName());
Best regards,
Oleg
