Raphaël Luta escribió:
>
> Santiago Gala wrote:
> >
> > Raphaël Luta escribió:
> > >
> > > The dependency mechanism already exists in Turbine services and you don't even
> > > have to specify them manually.
> > > I don't see how the feed dameon can use the registry before it is initialized,
>when
> > > it tries to get a handle to the service through the static accessor class, the
> > > service framework kicks in and makes sure the service is initialized before
> > > handing back a reference to the singleton.
> > > Looking at the init code of the service, all the registries are loaded
>synchronously
> > > in the init method so either there's a bug in the Service framework or
> > > the interaction bug is more subtle between FeedDaemon and RegistryManager.
> >
> > They are loaded, but not refreshed. I get the following errors:
> >
> > [Thu Jan 25 10:54:11 GMT+01:00 2001] -- NOTICE -- BEGIN:
> > EntryInstantiator: Instantiating 5 Portlet(s) found in a Feed
> > [Thu Jan 25 10:54:11 GMT+01:00 2001] -- ERROR -- Null
> > PortletRegistry
> >
> > Printed from:
> >
> > EntryFactory.java
> > /**
> > This method might become obsolete in the future
> > */
> > public static PortletEntry getEntry(
> > org.apache.jetspeed.xml.api.registrymarkup.Entry real ) {
> >
> > //go through the registrymarkup capability-map and pull out the
> > //mime-types
> >
> > PortletEntry entry = new PortletEntry();
> > entry.setName( real.getName() );
> >
> > PortletRegistry registry = (PortletRegistry)RegistryManager
> >
> > .get(RegistryManager.PORTLET_REGISTRY);
> > if( registry == null ) {
> > //Warning to diagnose problem
> > Log.error( "Null PortletRegistry" );
> > }
> > ...
> >
> > This is after some changes I did to avoid previous errors.
> >
> > There is another error: when the FeedManager runs the second (and
> > successive) time, it spoils dynamic entries, with an error
> >
> > "Entry did'nt have the classname set"
> >
> > I have not been able to trace this one. Everything looks allright, but
> > it fails.
> >
> >
> > I am getting crazy trying to get rid of those problems, because I don't
> > understand how they are generated. Can you have a look to
> > them?
> >
>
> OK, I'll try to look into this during the week-end but I first want
> to finish my layout system proposal.
>
I think I found it. I will try to summarise, as an opportunity to get
corrected if I make some error in my reasoning.
The problem is with the sequence of initialization of services.
Turbine provides two "rounds" of initialization for services. In the
first round, services get called with a ServletConfig object. Here we
perform most of our work. In the second round, services get called
without any argument.
The problem is that we don't implement the second round init(). The
default behaviour in turbine for the secound round is to call
setInit(true). So, the problem is that a lot of times, our services are
requested while they are being initialized. The result is that turbine
will return the "half cooked" services to the thread aking for them.
I think the default behaviour in TurbineBaseService init() is wrong. A
better default would be something like:
init(Object), init(RunData) and init(ServletConfig) do setInit(true)
(Turbine should guarantee that only one of these methods is called for
each service)
public void init() throws InitializationException {
if(!getInit()) {
throw new InitializationException("Not yet inited");
}
}
As a default implementation it should not assume that any service is to
be considered initialized when asked for, specially since the default
first round init() does nothing. In the way I think it should be, a
service that overrides early init takes responsibility of setting init
to true, and one that does not override it gets inited right. The way it
is now, a service should override both methods if it does any
initialization, to avoid race conditions like the ones we have.
But maybe I did not understand turbine model here. I would like to be
corrected if my reasoning is wrong.
I have fixed the problems by implementing late init methods in some
services (I will check for all and every service that has initialization
process). This implementation waits for getInit() returning true, while
printing messages every 100 milliseconds, to avoid either having an
exception thrown or delivering a service that is "on its way".
Some of the services implementation used synchronized in the two init to
have mutual exclusion between both initializations. It will not work,
except by locking turbine if some service is requested during
initialization of other service.
This are the dependencies I think we have:
URLManager depends on EngineContext (for settings of paths)
RegistryManager depends on URLManager (for the cache)
ProfileManager depends on Registrymanager (for MediaRegistry)
DaemonService depends on (some of the daemons) URLManager and
RegistryManager (cache and PortletRegistry)
There are possibly other dependencies around. In fact, most of the
services depend on the RegistryManager service.
Comments?
> --
> Raphaël Luta - [EMAIL PROTECTED]
> Vivendi Universal Networks - Services Manager / Paris
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
