Re: Registration done - next steps. Re: Problems Registering a XPCOM com
Jani <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.java |
|---|---|
| Message-ID | <6779334.post__49859.8592159853$1160672691$gmane$org@talk.nabble.com> |
Hi Martini,
I am developing xpcom component for my xulrunner based
application for Mac as well as Windows. My XULRunner based App is not
detecting the newly created xpcom compoent i.e .xpt file and .dll/.dylib
file. While googling about this , i came across your post.As you have
mentioned , you have forced the
re-registration programatically to work for u.. Can you please provide code
/ procedure for re-registration process.My XULRunner based application has
this Folder Structure.Thanks in Advance
On Windows File Structure is
TestApp
|
|
|------- application.ini file
|
|------- chrome folder
| |
| |-------chrome.manifest file
| |
| |--------content folder
| |
| |-------- main.xul
|
|-------defaults folder
| |
| |---- preferences folder
| |------------------prefs.js file
|
|------ components folder
| |
| |-------Test.xpt
| |
| |-------Test.idl
|
|------xulrunner Folder ( provided by mozilla)
|
|
|------ TestApp.exe ( sulrunner stub file)
Is this structure correct for XPCOM Components or is there any other
location i need to place my xpcom files.
Thanks,
JanakiRam.
Martini wrote:
>
> 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
>
> _______________________________________________
> dev-tech-java mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-java
>
>
--
View this message in context: http://www.nabble.com/Problems-Registering-a-XPCOM-component-in-XULrunner-environment-Re%3A-Question%3A-How-to-reliably-create-a-XPCOM-component-for-use-with-javaxpcom--tf2035009.html#a6779334
Sent from the Mozilla - OJI mailing list archive at Nabble.com.