Our setup:
We have some zone level extensions, and each room is created dynamically with a room level extension.
One of the zone level extensions has a static _instance member, which it sets to 'this' during init(), a bit like a singleton. The room level extension, which is created dynamically well after the zone is created, has had no problems utilizing this static instance value until now.
e.g.
Code: Select all
public class MyZoneExtension extends AbstractExtension
{
private static MyZoneExtension _instance = null;
public void init()
{
_instance = this;
}
public static void Test()
{
// _instance is null here if called from RoomExtension,
// but ok if called from ZoneExtension
_instance.trace("blah");
}
}
public class MyRoomExtension extends AbstractExtension
{
public void Test()
{
MyZoneExtension.Test();
}
}
The _instance value in the zone level extension is set properly, and even used by the zone level extension first, but when the room level extension comes along to use it, the _instance value is null (and no code exists to set _instance other than the one place in init()).
As a test, I tried removing all the static functions from the zone level extension, and instead called zone.getExtension() in the room level extension to get the instance. However this still did not work; a ClassCastException was thrown when trying to cast the zone level extension to itself.
After some investigation (and we're approaching the limits of my java knowledge now), it seems that perhaps more than one classloader has been used, so the static members of the zone level extension are not available/the same as the static members of the zone-level extension as loaded by the room level extension, since they have different Class instances.
I found a potential workaround, which was to add javaExtensions/ to the classpath in wrapper.conf. Then the room level extension seems to see the static values of the zone level extension, presumably because when the Classes are loaded, they find the same ones. However, I also found a post on the forums from Lapo saying to remove the javaExtensions/ folder from the classpath.
So my questions:
- in the default wrapper.conf I just installed, the java classpath includes sfsExtensions/. Aren't those only ActionScript extensions, so why are they in the java classpath?
- changing sfsExtensions to javaExtensions in the java classpath in wrapper.conf seems to fix the issue with the classloader, but it was advised against in this older post (viewtopic.php?t=365&highlight=classpath+sfsextensions). Is that information out of date, or is there another solution for my problem that is apparent?
- assuming I do want to change it, when I go to run as a service, presumably I'll update start.bat/.sh similarly?
- were there changes between 1.6.2 and 1.6.6 that could have caused, or even just exposed, this issue?
- during my search I also came across some threads from Lapo indicating that there should really only be one zone level extension per zone (viewtopic.php?t=1985&highlight=singleton+null). The diagram in section 6.2 of the docs shows two extensions. Is consolidating everything into one necessary?
Thanks!