Georges Racinet - 10/05/07 14:48 +1 on what Anahide said. Although adding some more logging can be done quickly, in the long run we'd need a debug mode under which NXRuntime would have zero tolerance.

Bogdan Stefanescu - 16/05/07 10:27 Actually this case is logged. When you register an extension but the target component is not registered you have the log (you should be in a log level >= DEBUG)             if (log.isDebugEnabled()) {                 log.debug("Enqueue contributed extension to pending queue: " + extension);             } The case when the extension point doesn't exists is not logged. Note that if the extension target component is not registered doesn't necessarily means you made a typo. This can be the case if the target component is deployed after the extension. And this is handled by nxruntime by adding the extension into a pending queue to be deployed later when the target component becomes available. So this is not a bug, I agree we should refine the way errors are handled and reported but this is another aspect. If you have suggestions open another task on this. A better way to debug nxruntime registry is to write an administration tool for nxruntime able to display the component registry, pending extensions etc.

Olivier Grisel - 16/05/07 11:41 I do think this is a huge productivity problem when working with the Nuxeo platform and it really deserves a fix. There should be an easy way to spot dependency typos at least at info level by the "end of a jboss boot". For instance it, is it possible to log a report of the queued registration just before the "JBoss started in xx hours^W minutes" info line? Granted that the "end of a jboss boot" does not exists in the OSGi framework since one can still register new components till the end of a nxruntime cycle. But to the programmer / integrator this is a real PITA to test her application manually and then encounter unexpected behaviors that are sometimes a non trivial consequence of an unitialiased component and then have to grep 5MB of logs at level debug to find out what happened. We also definitely need a OSGi dashboard page that displays the current list of registered components, the list of dependencies that are not met and a refresh button to reload some of them live when possible (for instance those that are -bundle.xml files deployed in the deploy/nuxeo.ear/config/ folder and that are meant to be edited after a build/deploy). A graphviz map of the loaded components would be even greater.

Bogdan Stefanescu - 21/05/07 11:32 Please let this one closed and add your proposals about nxrutnime administration features to http://jira.nuxeo.org/browse/NXP-172 The Extension Point Administration is a feature that should handle this kind of problems.