Hi gang,
Problem
=======
working on some Tweety demos I found that anything more than the
simplest of examples runs you into ConcurrentModificationExceptions and
stuff like that. The root of the problem is that for any real avalon
lifecycle demo, you need to satisfy the ServiceManager contract, for
which you need to map dependencies.
example:
tweety.properties
-----------------
com.leosimons.test.Component1=com.leosimons.test.Component1Impl
com.leosimons.test.Component2=com.leosimons.test.Component2Impl
com.leosimons.test.Component3=com.leosimons.test.Component3Impl
sources
-------
class Component1Impl implements Component1
{
// ...
}
class Component2Impl implements Component2
{
// ...
}
class Component3Impl implements Component3
{
// ...
service( ServiceManager sm )
{
Component1 c1 = (Component1)sm.lookup(Component1.ROLE);
Component2 c2 = (Component2)sm.lookup(Component2.ROLE);
}
// ...
}
This leads to problems because the service()ing is done while it is
still possible that tweety might add stuff into the sm as well.
Possible fixes
==============
Easiest fix
-----------
The easiest way to avoid this is to only store the sm and then lookup
stuff in or after start():
class Component3Impl implements Component3
{
ServiceManager m_sm;
// ...
service( ServiceManager sm )
{
m_sm = sm;
}
// ...
start()
{
Component1 c1 = (Component1)m_sm.lookup(Component1.ROLE);
Component2 c2 = (Component2)m_sm.lookup(Component2.ROLE);
}
// ...
}
which is of course an invalid assumption of the framework contract.
Quickest fix
------------
I ripped the DAG code for that from phoenix, threw in some i18n and some
more 'solidness' and I had myself something similar to the
MicroContainer Leo Sutic built some time ago. And it was also way more
complicated than Tweety should be.
The right fix?
--------------
The question now is: how does one implement the dependency mapping that
ServiceManager needs in the simplest way possible?
Some options crossed my mind:
- express dependencies as ordering inside a .properties file: all items
that come below another one are allowed to depend on the ones above
them. Bad because ordering of properties is not the way property files
normally work and it adds additional semantics.
- express dependencies in an ant-like fashion. Ie replace the properties
file with something like
tweety.config
-------------
<component role="blah1" class="com.foo.blah1"/>
<component role="blah2" class="com.foo.blah2"/>
<component role="blah3" class="com.foo.blah3" requires="blah1,blah2"/>
this could set us on the road to complex container land.....
- dissallow dependencies, ie not support ServiceManager. The perceived
added value of the framework goes to zero.
- express dependencies in object form, ie:
public class DependencyInfo
{
private String[] m_roles;
public DependencyInfo(String[] roles)
{
m_roles = roles;
}
/** return true if a component needs this, false otherwise */
public boolean requires( String role )
{ /* impl */ }
}
class Component3Impl implements DependencyInfo
{
// can never remember this syntax but you get the idea :D
public final static DependencyInfo DEPENDENCIES =
new DependencyInfo( new String[] {
Component1.ROLE,
Component2.ROLE } );
}
anyone with other ideas? Suggestions? Comments? Kinda stuck here. The
right balance between simplicity and complexity is real important at
this point ;)
Oh, and it might be that it is impossible to do this cleanly and the
effort should be dropped...... :D
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
