Registration done - next steps. Re: Problems Registering a XPCOM component in XULrunner environment Re: Question: How to reliably create a XPCOM component for use with javaxpcom?

Benjamin,

Thanks for the response - that makes sense to me right now.
I forced re-registration programmatically as you suggested which works
well.

Now the next steps are really puzzling me - the test component that I
have implements a generic factory of an object that implements the
dsTestEntryPoint interface through the macro:
NS_GENERIC_FACTORY_CONSTRUCTOR(TestEntryPoint)

What I am seeing though is that if I attempt to create the instance via

componentManager.createInstanceByContractID(NS_TESTCOMPONENT_CONTRACTID,
null,	dsTestEntryPoint.DSTESTENTRYPOINT_IID);

I get an exception being thrown from the JavaXPCOM layer.


java.lang.NoClassDefFoundError: org/mozilla/xpcom/dsTestEntryPoint
	at org.mozilla.xpcom.internal.XPCOMJavaProxy.callXPCOMMethod(Native
Method)
	at
org.mozilla.xpcom.internal.XPCOMJavaProxy.invoke(XPCOMJavaProxy.java:140)
	at $Proxy4.queryInterface(Unknown Source)
	at TestCustomComponent.main(TestCustomComponent.java:124)


I'm not sure what to make of it.


Martin


Benjamin Smedberg wrote:
> Martini wrote:
> > I just realized there's a more succinct way to describe my problem:
> > I have created a XPCOM standalone component that provides some service
> > that I want to access in my self contained XUL dev environment.
> > How do I register it so that it is available for use just like the
> > components in xulrunner/components
>
> What environment is this? A XULRunner app, or embedded? If it's a XR app,
> all you need to do is put the component in <app>/components and force
> reregistration of components. That's best done by changing the buildid in
> application.ini
>
> In embedded contexts, you will need to specify a directory to look for
> components during XPCOM initialization. You may also need to force component
> registration programmatically (nsIComponentRegistrar.autoRegister(null)).
>
> > The obvious way of registering with regxpcom is not resulting in the
> > updated components/*.dat files.
>
> No toolkit-based apps should ever use regxpcom. It is a holdover from the
> days when we kept compreg.dat in the application directory and is totally
> unreliable.
> 
> --BDS