I already implemented a (request based) system where a token
(some request object) was used as a key and all requested
objects tracked that way.
We already talked about that here, remember?
Someone even suggested that each "client" process would
request any resources to the container trough a Session
object (which is more elegant than my initial approach).
Closing the Session would trigger the cleanup, but the
client process could also ask for a cleanup operation
for a given stage of its work (maybe even using another
resource tracking sub-Session).
So, a client process/thread would lookup and obtain
resources only through a Session.
Hum... can't resist some code, can I?
For starters, the TheContainer interface looks like this:
public interface TheContainer
{
WorkSession getSession();
}
If you want to do anything with it, you must first get a
WorkSession.
And then, guess the rest from the sample of a client class:
public class WorkingClass implements WorkerBee
{
// from the WorkerBee interface...
public void work(TheContainer i_container, WorkParams i_params)
{
// If I need to lookup stuff, I need a Session
WorkSession mySession = i_container.getSession();
try
{
MyResource res1 =
(MyResource)mySession.lookup("my.stuff.MyResource", "the-hint");
...
// sub-session use:
WorkSession subSession = mySession.getSession();
try
{ subTask(subSession, i_param.getSomeParams());
}
finally
{ // Cleanup subTask()'s mess!
subSession.dispose();
}
...
}
finally
{
// subSession would also be disposed here...
mySession.dispose();
}
}
private void subTask(WorkSession mySession, SomeParams i_param)
{
OtherStuff os = (OtherStuff)mySession.lookup(....);
os.workitOut(i_param.getXpto());
...
}
}
Another way is that the client class is only given a Session
fom its master application structure:
public class WorkingClass implements WorkerBee
{
// from the WorkerBee interface...
public void work(WorkSession i_session, WorkParams i_params)
{
....
}
Remarks?
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]
> Sent: quarta-feira, 23 de Julho de 2003 17:50
> To: 'Avalon Developers List'
> Subject: RE: [RT] Distant Future...
>
>
>
>
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]
> >
> > a nice reference to what you are
> > referring to the first time would help.
>
> You are right. Point taken.
>
> In this case, http://www.picocontainer.org is the proper site
> to check.
>
> > I would prefer something that didn't require a try/finally
> > approach because we are imposing too much on the developer.
> > Remember simplicity--and the question becomes for who are
> > things simplified?
>
> For container and component writer, I think. As it is now we have
> a lot of features in the containers making them hard to write.
>
> At the same time, using these features aren't trivial, so the
> component writer had better understand a lot.
>
> Take Fortress's async release of components. The only reason
> we have that is because we support transient and poolable
> object (only really the latter).
>
> Do we really need transient and poolable components in the
> shape & form we have now?
>
> Take Fortress's async init - the first feature request for the
> init sequence was to be able to run it in the main thread
> (init = inline).
>
> So my question is this - are all those features really needed,
> or are they just patches on top of a contract that simply put
> promises to do too much? Can we simplify things by promising
> *less*?
>
> > My version of simplicity will allow the container to adapt
> > so that there are very little real requirements on the
> > component writer.
>
> Would this be similar to the subsystem approach that WinNT has?
> I.e. you have an NT kernel, and then you can run a Win32 subsystem
> on top of it, a POSIX subsystem, etc.?
>
> This sounds much like a containerkit. If there are few requirements
> on the component writer, then there must be more requirements
> on writing that subsystem - after all, I'll never be able to just
> throw random code at the container and have it figure everything
> out automagically.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
