You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leif Mortenson <le...@tanukisoftware.com> on 2003/05/14 19:41:31 UTC
[Fortress] Dispose and dependencies
I have been having problems with the order that Fortress disposes its
components on shutdown. Components are being disposed in the order
that they are declared in the xconf configuration file. Say I have the
following components:
compA
compB looks up and depends on compA
compC looks up and depends on compB
Because Fortress is disposing compA then compB, compC is encountering
various problems because the services that it relies on have been disposed
out from under it.
It seems like the this is breaking the contracts promised by ServiceManager
as the compA and compB should never be disposed until compC has been
disposed.
The ECM handles this correctly. Is this expected? Is there something that
I may be configuring incorrectly?
If I very carefully place the services in the order that they can be safely
disposed, into the xconf file, then I can get my application to work on
shutdown. But it does not seem like this should be necessary.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Dispose and dependencies not only in Fortress
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
> Berlin,
> I have been trying to dig in and figure out how to get the Fortress
> to use
> the Meta information but have not been having much success. I have not
> been able to find any place where the process is described.
>
> I have been able to generate meta information for my services by using
> the following task in my build.xml file:
> <taskdef name="collect-metainfo"
> classname="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector">
> <classpath>
> <path refid="project.class.path"/>
> </classpath>
> </taskdef>
> <collect-metainfo destdir="${build.classes}">
> <fileset dir="${src.dir}"/>
> </collect-metainfo>
>
> This will collect the meta information for all of the classes in the
> current
> project. But how do you collect meta information for classes like
> JdbcDataSource? They appear to have the meta information defined in
> their source, but the jar files do not currently contain any meta info.
> This
> makes me think that I am missing something.
Right now, that is taken care of by the FortressRoleManager. If you
don't specify any role managers in your system, this will be created
for you anyway. In the future the datasource jars will have all the
required information.
>
> Second. How do I tell Fortress to make use of the meta information
> in the Jars. Up until this point, I have been specifying a roles config
> file
> and using the RoleManager. From digging around in the code, It looks
> like I want to be using the ServiceMetaManager, but have not yet figured
> out how to tell Fortress to use it.
Fortress will always use the MetaInfoManger. Unless you override the
MetaInfoManager, the ContextManager will create a new
ServiceMetaInfoManger which uses all the stuff that the ANT task
generates. The ServiceMetaInfoManager wraps any RoleManager (or the
root FortressRoleManager) in the default context.
In short--it always uses it.
>
> Sorry if I am missing something obvious. After too many hours of
> looking
> through code and list archives, something is just refusing to click :-/
> Things
> may make more sense in the morning.
>
> Any help would be appreciated.
> Cheers,
> Leif
The code is being cleaned up to be a bit easier on the eyes.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Dispose and dependencies not only in Fortress
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berlin,
I have been trying to dig in and figure out how to get the Fortress
to use
the Meta information but have not been having much success. I have not
been able to find any place where the process is described.
I have been able to generate meta information for my services by using
the following task in my build.xml file:
<taskdef name="collect-metainfo"
classname="org.apache.avalon.fortress.tools.ComponentMetaInfoCollector">
<classpath>
<path refid="project.class.path"/>
</classpath>
</taskdef>
<collect-metainfo destdir="${build.classes}">
<fileset dir="${src.dir}"/>
</collect-metainfo>
This will collect the meta information for all of the classes in the
current
project. But how do you collect meta information for classes like
JdbcDataSource? They appear to have the meta information defined in
their source, but the jar files do not currently contain any meta info.
This
makes me think that I am missing something.
Second. How do I tell Fortress to make use of the meta information
in the Jars. Up until this point, I have been specifying a roles config
file
and using the RoleManager. From digging around in the code, It looks
like I want to be using the ServiceMetaManager, but have not yet figured
out how to tell Fortress to use it.
Sorry if I am missing something obvious. After too many hours of
looking
through code and list archives, something is just refusing to click :-/
Things
may make more sense in the morning.
Any help would be appreciated.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Dispose and dependencies not only in Fortress
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
>
> BL> It requires using the @avalon.dependency type="my.com.Role"
> BL> doc tag to provide the dependency information.
>
> Does this approach have the potential to grow into an architecture
> where Components will be allowed to lookup _only_ the roles
> that have been specified in @avalon.dependecy (or via some other
> way in the meta-descriptors) ?
Yes. In fact, our more full featured containers already implement
this. I merely took the already declared usage pattern from them,
and implemented it in a less strict way in Fortress.
>
> Maybe not now but in Avalon 5 ?
No, it is preferable to limit the scope of what a component can
lookup, but there are some things to work out first.
>
> <implementation-thoughts>
> I doubt how much overhead this may bring.
> Probably each component class could be wrapped into an
> additional auto-generated subclass (this will strictly require BCEL)
> that would overload the service() method - and in this method the role
> might be compared against a static HashSet or sequentially
> against every role in the list - shouldn't take long as
> the list of used components is usually quite limited, isn't it?
> Probably if it is enough to compare strings as '==' not .equals.
> (only the generated strings that have not been .intern()-ed
> are an issue, aren't they? but such case may be safely ignored,
> especiall as everyone uses Blah.ROLE)
> </implementation-thoughts>
There are other ways of doing it without requiring BCEL. In fact,
since every component gets their own instance of the servicemanager,
it is very easy to only map what needs to be mapped.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Dispose and dependencies not only in Fortress
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello, Berin!
BL> It requires using the @avalon.dependency type="my.com.Role"
BL> doc tag to provide the dependency information.
Does this approach have the potential to grow into an architecture
where Components will be allowed to lookup _only_ the roles
that have been specified in @avalon.dependecy (or via some other
way in the meta-descriptors) ?
Maybe not now but in Avalon 5 ?
<implementation-thoughts>
I doubt how much overhead this may bring.
Probably each component class could be wrapped into an
additional auto-generated subclass (this will strictly require BCEL)
that would overload the service() method - and in this method the role
might be compared against a static HashSet or sequentially
against every role in the list - shouldn't take long as
the list of used components is usually quite limited, isn't it?
Probably if it is enough to compare strings as '==' not .equals.
(only the generated strings that have not been .intern()-ed
are an issue, aren't they? but such case may be safely ignored,
especiall as everyone uses Blah.ROLE)
</implementation-thoughts>
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Step three todo:
>
> Use the topological sort to organize the shutdown list....
>
> Granted this only works with the MetaInfoManager.
>
>
Initial support done. It needs testing though. It is also
much more inclusive than either Merlin or Phoenix as far as
checking dependences. It will check every implementation of
every role that is implemented to look for loops, and ensure
a proper shutdown list.
It requires using the @avalon.dependency type="my.com.Role"
doc tag to provide the dependency information.
There is one issue regarding the AMTAGS proposal and Fortress,
other than the fact that the "optional" property is not supported:
There is no way to specify selector or Role/entry to narrow the
scope. That can be worked out later though.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Leif Mortenson wrote:
>
> Good, I had seen comments about Fortress not maintaining a
> dependency tree and thought maybe this was expected. The ECM used
> to have this same problem but Ryan and I added a system of reference
> counters in the handlers of each component. Each time get or put was
> called they would be incremented or decremented appropriately.
>
> Disposing the components is then as simple as going into a while loop
> where you loop over all of the undisposed components, disposing any
> which have a reference count of 0. If you ever make it through the loop
> without finding any 0 reference counts then you know that someone
> forgot to dispose a component correctly, at which point anything goes
> and you just dispose the remaining components, with warnings.
>
> This is causing me problems so I'll go in and take a look at it. Does the
> above sound Ok for Fortress? Or was there a plan for how this was
> supposed to work? It may be obvious once I dig into the code.
Step one complete:
Incorporate DAG verification classes in Fortress util.
Step two complete:
Add verification so that no circular dependencies should appear in
a file (the build exception will let you know what is going on).
Step three todo:
Use the topological sort to organize the shutdown list....
Granted this only works with the MetaInfoManager.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Thursday, May 15, 2003, at 12:13 PM, Berin Loritsch wrote:
>
>> Actually I have been busy writing a Directed Acyclic Graph utility that
>> #1 verified if there were any circular dependencies, and #2 sort the
>> components so that all dependencies are tracked in order. The
>> topological sort algorithm is pretty quick, and the algorithm itself
>> is reusable.
>
>
> Doesn't Phoenix have code like this for ordering block startup?
> (reinvent the wheel, etc, etc)
Dunno. I'm done with it, so I can incorporate the changes to Fortress
easily.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Peter Royal <pr...@apache.org>.
On Thursday, May 15, 2003, at 12:13 PM, Berin Loritsch wrote:
> Actually I have been busy writing a Directed Acyclic Graph utility that
> #1 verified if there were any circular dependencies, and #2 sort the
> components so that all dependencies are tracked in order. The
> topological sort algorithm is pretty quick, and the algorithm itself
> is reusable.
Doesn't Phoenix have code like this for ordering block startup?
(reinvent the wheel, etc, etc)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Thursday, May 15, 2003, at 11:47 AM, Leif Mortenson wrote:
>
>> This is causing me problems so I'll go in and take a look at it. Does
>> the
>> above sound Ok for Fortress? Or was there a plan for how this was
>> supposed to work? It may be obvious once I dig into the code.
>
>
> Sounds okay to me... I don't know of any other plans (I imagine Berin
> would have spoken up if he had any) .. it'll just be imperative that
> components always release components that they've lookup()'d in order
> for that to work properly.
> -pete
Actually I have been busy writing a Directed Acyclic Graph utility that
#1 verified if there were any circular dependencies, and #2 sort the
components so that all dependencies are tracked in order. The
topological sort algorithm is pretty quick, and the algorithm itself
is reusable.
I really wanted to use it for the bundle API I am working on--but I
can port it over to Fortress as well.
The only thing remaining is to add support for Fortress to track
dependencies and we can ensure a proper shutdown order (and even
a startup order...).
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Peter Royal <pr...@apache.org>.
On Thursday, May 15, 2003, at 11:47 AM, Leif Mortenson wrote:
> This is causing me problems so I'll go in and take a look at it. Does
> the
> above sound Ok for Fortress? Or was there a plan for how this was
> supposed to work? It may be obvious once I dig into the code.
Sounds okay to me... I don't know of any other plans (I imagine Berin
would have spoken up if he had any) .. it'll just be imperative that
components always release components that they've lookup()'d in order
for that to work properly.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Peter Royal wrote:
> On Wednesday, May 14, 2003, at 01:41 PM, Leif Mortenson wrote:
>
>> It seems like the this is breaking the contracts promised by
>> ServiceManager
>> as the compA and compB should never be disposed until compC has been
>> disposed.
>>
>> The ECM handles this correctly. Is this expected? Is there something
>> that
>> I may be configuring incorrectly?
>>
>> If I very carefully place the services in the order that they can be
>> safely
>> disposed, into the xconf file, then I can get my application to work on
>> shutdown. But it does not seem like this should be necessary.
>
>
> I think you found a bug :)
> -pete
Good, I had seen comments about Fortress not maintaining a
dependency tree and thought maybe this was expected. The ECM used
to have this same problem but Ryan and I added a system of reference
counters in the handlers of each component. Each time get or put was
called they would be incremented or decremented appropriately.
Disposing the components is then as simple as going into a while loop
where you loop over all of the undisposed components, disposing any
which have a reference count of 0. If you ever make it through the loop
without finding any 0 reference counts then you know that someone
forgot to dispose a component correctly, at which point anything goes
and you just dispose the remaining components, with warnings.
This is causing me problems so I'll go in and take a look at it. Does the
above sound Ok for Fortress? Or was there a plan for how this was
supposed to work? It may be obvious once I dig into the code.
Cheers,
Leif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] Dispose and dependencies
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, May 14, 2003, at 01:41 PM, Leif Mortenson wrote:
> It seems like the this is breaking the contracts promised by
> ServiceManager
> as the compA and compB should never be disposed until compC has been
> disposed.
>
> The ECM handles this correctly. Is this expected? Is there something
> that
> I may be configuring incorrectly?
>
> If I very carefully place the services in the order that they can be
> safely
> disposed, into the xconf file, then I can get my application to work on
> shutdown. But it does not seem like this should be necessary.
I think you found a bug :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org