The way ExternalContext was implemented before it was assumed that clients
would not close a Context that was mapped by ExternalContext. I added a
CacheContext attribute that when true, keeps the extern Context in memory
and returns a proxy on lookup that ignores close methods. Client can invoke
close on the Context, but the external Context is not closed until the ExternalContext
service is stopped.When CacheContext is false the extern Context is created on each
lookup and its up to the client to invoke close to reclaim the Context resources or
let the garbage collector do it.
In general a client can invoke close on a Context to free any associated resources
rather than waiting for garbage collection. Its not required but not invoking close
can waste resources like connections.
----- Original Message -----
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 23, 2001 12:16 PM
Subject: Re: [JBoss-dev] ExternalContext & Context.close()
> Aren't clients expected to close contexts? Or are they only expected to
> close InitialContexts?
>
> --jason
>
>
> On Thu, 19 Apr 2001, Scott M Stark wrote:
>
> > The Context mapped via ExternalContext is only created on startup of the mbean
> > and closed when it is stopped. To be able to issue a close on the context there
> > I would have to add a CacheContext attribute that if set to false would result in
> > the external context being created on each lookup and would have to be closed
> > by the client performing the lookup.
> >
> > ----- Original Message -----
> > From: "Jason Dillon" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, April 19, 2001 12:27 PM
> > Subject: [JBoss-dev] ExternalContext & Context.close()
> >
> >
> > > I just ran into a problem if I closed a Context that was mapped from
> > > ExternalContext ala:
> > >
> > > <mbean code="org.jboss.naming.ExternalContext"
> > > name=":service=ExternalContext,name=Dispatcher">
> > > <attribute name="RemoteAccess">false</attribute>
> > > <attribute name="JndiName">external/dispatcher</attribute>
> > > <attribute name="InitialContext">javax.naming.InitialContext</attribute>
> > > <attribute name="Properties">somefile.properties</attribute>
> > > </mbean>
> > >
> > > The client looks something like this:
> > >
> > > Context context = (Context)new
> > > InitialContext().lookup("external/dispatcher");
> > >
> > > ... some other look ups
> > >
> > > context.close();
> > >
> > > There are a couple of bits that use similar code to above (all trying to
> > > access the same external context). If I remove Context.close() calls then
> > > everything works, but if I try to close them, I get some very odd behavior
> > > (one instance of each class will function, but all other will fail + more).
> > >
> > > >From looking at ExternalContext, I can not see anything obvious that could
> > > cause this behavior. For now I can just not close these contexts (but I am
> > > under the impression that I probably should).
> > >
> > > Perhaps Scott would no best, but is this the correct behavior that I should
> > > be seeing. If you would like more detail I can provide that (such as how to
> > > get a NullPointerException from inside of javax.naming.InitialContext when
> > > attempting to call addToEnviorment() and such).
> > >
> > > --jason
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
