Questions about class loader, singleton, upgrade to 1.6.6

Post here your questions about Actionscript and Java server side extensions development.

Moderators: Lapo, Bax

Molix
Posts: 40
Joined: 01 Apr 2009, 19:34
Location: Toronto, ON, Canada

Questions about class loader, singleton, upgrade to 1.6.6

Postby Molix » 30 Sep 2009, 18:23

I'm in the process of upgrading from 1.6.2 to 1.6.6, and some issues have appeared.

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!
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 03 Oct 2009, 13:39

Hi,
the fundamental problem with class loaders is determined by the presence of the javaExtensions folder in the classpath.
Take a look here:
http://www.smartfoxserver.com/docs/docP ... ions.htm#9

Each extension is loaded in a different Class Loader, hence the cast exception. But there's a catch: if javaExtensions/ is in the classpath your classes will be loaded first by the System Class Loader and you won't get any class cast exceptions.
- 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?

sfsExtensions does not affect java code.

- 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?

As explained above in this way the System Class Loader will load your classes, so they will be seen globally. It can be used but it will inhibit runtime reloading of your extensions. (again see the above link)

- assuming I do want to change it, when I go to run as a service, presumably I'll update start.bat/.sh similarly?

yes

- were there changes between 1.6.2 and 1.6.6 that could have caused, or even just exposed, this issue?

Yes, if remember correctly javaExtensions was removed from the classpath to make the Extension AutoReload feature work out of the box.

- 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?


One Extension per Zone is recommended especially using languages like Java. The diagram in 6.2 simply shows how Extensions can be plugged at different levels.
Lapo
--
gotoAndPlay()
...addicted to flash games
Molix
Posts: 40
Joined: 01 Apr 2009, 19:34
Location: Toronto, ON, Canada

Postby Molix » 03 Oct 2009, 13:49

I think I understand. So with javaExtensions in the classpath, I won't be able to do the AutoReloadExtension (I can live with that; I couldn't seem to get it to work anyway). The sfsExtensions in the installer's classpath must just be a typo/bug. And it is good to know that something changed between the versions which explains the problem, so I can move on.

Thanks for the clarification Lapo.
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Postby Lapo » 05 Oct 2009, 08:10

The sfsExtensions in the installer's classpath must just be a typo/bug.

No that's necessary as well, but it doesn't interfere with your Java code. Of course if you plan to never use script-based code then you can remove it.
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “Server Side Extension Development”

Who is online

Users browsing this forum: No registered users and 34 guests