java wucalsses don't work

[curtis1213]

When I traced the code, I commented all native wuclasses in enabled_wuclass.xml to make sure there is initially no native wuobject in the wudevice. Then I deployed a virtual wucalss, and found out that wkpf_get_wuobject_by_port() returned error, which is in line 308 in wkpf_links.c. Therefore the function returned in line 310. And I also checked whether there is java wuobject by checking status of the wudevice in discovery phase. There is only a generic wuobject on the list. I think the java wuobject wasn't generated.

[curtis1213]

Have you checked on the node to verify that the wuobject has not been created? Also could you tell us whether the wuobject property value/status is read? Can you trace and pinpoint the bug?

And when it return errors, what error? how does it occur, what do you think we can do to fix it? just describe it briefly, but it would help to advance this discussion a bit faster.

Sincerely, Penn

[pencilcheck]

That's weird. Github reply didn't reply on this thread. Sorry about for the small spam.

Anyway, have you find out the problem and fixed it yet?

[curtis1213]

I tried to reply but deleted your response accidentally, sorry for that.

The property value is read in function wkpf_process_initvalues_list(). But before getting property value, the wuobject has to be got from wuobject list. This function named wkpf_get_wuobject_by_port() is used to get wuobject by its port number, but it can't be find from wuobject list. Then the function returns error message so that the wkpf_process_initvalues_list() jumps out before reading the property value.

And as mentioned before, I checked the wuobject list of wudevice by browser in discovery phase. There is no java wuobject inside. Combining these two reason, I believe the java wuobject didn't be created.

I think the java wuobject is created by master server and I am not familiar with the master code, correct me if I wrong about this conception.

[pencilcheck]

And yes, that's why I want you to check the things I listed in my previous reply. Have you done that yet?

[curtis1213]

Yes, I checked the node.

[pencilcheck]

Yes. What did you check? Have you checked the code that initialize the wuobjects? do you see anything there?

Also could you tell us whether the wuobject property value/status is read? Can you trace and pinpoint the bug?

And when it return errors, what error? how does it occur, what do you think we can do to fix it?

[curtis1213]

I don't get it, I thought my response is clear. The property value is read after that java wuobject is got. But the java wuobject is missing, so property value is not read. And the error occurs because of the lost of java wuobject. And I think the java wuobject is created by master server and I am not familiar with the master code, I don't know where to start to find the bug, correct me if I wrong about this conception.

If you have time in tomorrow noon, maybe we can meet at 7F lab to discuss.

[pencilcheck]

NanoKong Darjeeling VM will first register virtual wuclasses and create wuobjects on start, then it will setup the properties with initial values provided from the xml.

If the wuobjects or wuclasses are not registered correctly, then master of course will not be able to discover them, that's why I want you to verify that the VM does indeed register the virtual wuclasses, and create the wuobject on start up.

[curtis1213]

progress update: at 45th line of wkpf_wuobjects.c

if (!(wuclass->flags & WKPF_WUCLASS_FLAG_APP_CAN_CREATE_INSTANCE) && !called_from_wkpf_native_wuclasses_init) return WKPF_ERR_CANT_CREATE_INSTANCE_OF_WUCLASS;

When VM tries to create java wuobject, it fails due to "wuclass->flags" is 0 and "called_from_wkpf_native_wuclasses_init is false". I haven't understood the meaning of "flags" and why it is set by 0 yet, so I don't know how to fix it.

The "flags" of native wuclass is also 0, but its "called_from_wkpf_native_wuclasses_init" is true. Therefore its wuobject could be created.

[pencilcheck]

flags is 0 but WKPF_WUCLASS_FLAG_APP_CAN_CREATE_INSTANCE is 1, so that means the expression should evaluate to be false, which will in return be true negated by the outside !, and that's why this wuclass cannot be instantiated.

Niels, can you tell us what the value of flags is suppose to be for virtual wuclasses? It looks like you didn't set the flags when you register virtual wuclass. (wkpf_virtual_wuclasses.c:8)

[nielsreijers]

Sorry, just got home and it seems you guys solved the problem already. Yes, WKPF_WUCLASS_FLAG_APP_CAN_CREATE_INSTANCE should be true for virtual classes (or you could change wkpf_wuobjects.c:45 to just always allow virtual classes, but the first solution seems both cleaner and a tiny bit faster)

I can't really reconstruct it from the history, but what could have happened is that I created the picokong after the hard/soft refactoring branch was created. I remember that change was parked on a separate thread for quite some time, so it could be a case where two changes may be correct individually, but break when they get merged. Or maybe I just forgot about the virtual classes... Anyway, just setting the flag in wkpf_virtual_wuclasses.c should fix it. :-)

On Thu, Sep 12, 2013 at 9:38 PM, Penn Su notifications@github.com wrote:

flags is 0 but WKPF_WUCLASS_FLAG_APP_CAN_CREATE_INSTANCE is 1, so that means the expression should evaluate to be false, which will in return be true negated by the outside !, and that's why this wuclass cannot be instantiated.

Niels, can you tell us what the value of flags is suppose to be for virtual wuclasses? It looks like you didn't set the flags when you register virtual wuclass. (wkpf_virtual_wuclasses.c:8)

— Reply to this email directly or view it on GitHubhttps://github.com/wukong-m2m/wukong-darjeeling/issues/43#issuecomment-24349498 .

_

[curtis1213]

I turned on the flag of virtual wuclass, it should work now. The code has been pushed to merge-features branch.