Page 2 of 3
Posted: 19 Feb 2008, 14:31
by tobypb
I'm also experiencing this problem. But if I remove the classpath folder how will sfs know where to look for my java extension. When I remove the javaExtension/ folder from the classpath in wrapper.conf the server does not start properly for me presumably becuase the extension classes cannot be found.
At the moment the extension classes are all within the javaExtensions/ folder but not packaged in a jar. If I package them in a .jar and add this file location to the wrapper.conf will sfs reload the java extension each time it is modified?
Posted: 26 Feb 2008, 14:35
by Lapo
We can successfully reload extension without using the wrapper. I will check how the classpath is setup and see how we can make it work with the wrapper. Stay tuned
Posted: 26 Feb 2008, 14:41
by tobypb
niceone lapo! I look forward to your response as it will greatly increase my java dev speed!
This thread has reminded me of something else. The reason I was using the class files and not a packaged jar in the first place is that I tried putting the .jar in the javaExtensions folder but it would not be loaded. I did not know about the wrapper.conf file at this point though. To use .jar files do I have to edit the wrapper.conf file?
thanks as always!
Posted: 26 Feb 2008, 14:49
by Lapo
Yes, the wrapper conf file has a list of files that are included in the classpath, simply add your jar(s) following the convention in the file
cheers
Posted: 27 Feb 2008, 16:27
by Lapo
I tested a local installation of SFS 1.6.1 and didn't have problems reloading the extension class.
Actually both my start.sh and wrapper.conf don't contain the javaExtensions folder.
Here's my start.sh script:
java -cp "./:./sfsExtensions/:lib/activation.jar:lib/commons-beanutils.jar:lib/commons-collections-3.2.jar:lib/commons-dbcp-1.2.1.jar:lib/commons-lang-2.3.jar:lib/commons-logging-1.1.jar:lib/commons-pool-1.2.jar:lib/concurrent.jar:lib/ezmorph-1.0.3.jar:lib/h2.jar:lib/js.jar:lib/json-lib-2.1-jdk15.jar:lib/json.jar:lib/jsr173_1.0_api.jar:lib/jysfs.jar:lib/jython.jar:lib/nanoxml-2.2.1.jar:lib/wrapper.jar:lib/xbean.jar:lib/javamail/imap.jar:lib/javamail/mailapi.jar:lib/javamail/pop3.jar:lib/javamail/smtp.jar:lib/jetty/jetty-6.1.3.jar:lib/jetty/jetty-util-6.1.3.jar:lib/jetty/jstl.jar:lib/jetty/multipartrequest.jar:lib/jetty/servlet-api-2.5-6.1.3.jar:lib/jetty/standard.jar:lib/jsp-2.1/commons-el-1.0.jar:lib/jsp-2.1/core-3.1.0.jar:lib/jsp-2.1/jsp-2.1.jar:lib/jsp-2.1/jsp-api-2.1.jar:lib/jsp-2.1/jstl.jar:lib/jsp-2.1/standard.jar:" -Dfile.encoding=UTF-8 -Djava.util.logging.config.file=logging.properties it.gotoandplay.smartfoxserver.SmartFoxServer $1
And here's the wrapper.conf section of the classpath:
wrapper.java.classpath.1=./
wrapper.java.classpath.2=./sfsExtensions/
wrapper.java.classpath.3=lib/activation.jar
wrapper.java.classpath.4=lib/commons-beanutils.jar
wrapper.java.classpath.5=lib/commons-collections-3.2.jar
wrapper.java.classpath.6=lib/commons-dbcp-1.2.1.jar
wrapper.java.classpath.7=lib/commons-lang-2.3.jar
wrapper.java.classpath.8=lib/commons-logging-1.1.jar
wrapper.java.classpath.9=lib/commons-pool-1.2.jar
wrapper.java.classpath.10=lib/concurrent.jar
wrapper.java.classpath.11=lib/ezmorph-1.0.3.jar
wrapper.java.classpath.12=lib/h2.jar
wrapper.java.classpath.13=lib/js.jar
wrapper.java.classpath.14=lib/json-lib-2.1-jdk15.jar
wrapper.java.classpath.15=lib/json.jar
wrapper.java.classpath.16=lib/jsr173_1.0_api.jar
wrapper.java.classpath.17=lib/jysfs.jar
wrapper.java.classpath.18=lib/jython.jar
wrapper.java.classpath.19=lib/nanoxml-2.2.1.jar
wrapper.java.classpath.20=lib/wrapper.jar
wrapper.java.classpath.21=lib/xbean.jar
wrapper.java.classpath.22=lib/javamail/imap.jar
wrapper.java.classpath.23=lib/javamail/mailapi.jar
wrapper.java.classpath.24=lib/javamail/pop3.jar
wrapper.java.classpath.25=lib/javamail/smtp.jar
wrapper.java.classpath.26=lib/jetty/jetty-6.1.3.jar
wrapper.java.classpath.27=lib/jetty/jetty-util-6.1.3.jar
wrapper.java.classpath.28=lib/jetty/jstl.jar
wrapper.java.classpath.29=lib/jetty/multipartrequest.jar
wrapper.java.classpath.30=lib/jetty/servlet-api-2.5-6.1.3.jar
wrapper.java.classpath.32=lib/jetty/standard.jar
wrapper.java.classpath.33=lib/jsp-2.1/commons-el-1.0.jar
wrapper.java.classpath.33=lib/jsp-2.1/core-3.1.0.jar
wrapper.java.classpath.34=lib/jsp-2.1/jsp-2.1.jar
wrapper.java.classpath.35=lib/jsp-2.1/jsp-api-2.1.jar
wrapper.java.classpath.36=lib/jsp-2.1/jstl.jar
wrapper.java.classpath.37=lib/jsp-2.1/standard.jar
By activating the <AutoReloadExtensions> I get the extension properly reloaded as soon as the compilation finishes.
Let me know if it works for you
Posted: 27 Feb 2008, 18:11
by zood
Hi Lapo, and everyone ~
Lapo, your example worked for me, with one exception -- now I can't load my custom buddy persister class. I've been storing it as a .class file in the javaExtensions folder, specifically, a subfolder which is the top level container for my extensions package namespace.
When javaExtensions is in the classpath I can load my buddy persister class with <persisterClass>packagename.BuddyPersister</persisterClass>, but when it's not I can't... and I can't seem to work around this by adding this one class to the classpath in wrapper.conf. Should the buddy persister be compiled into a jar instead?
Can you suggest a solution that allows for dynamic extension class reloading and a custom buddy persister? Its probably a simple classpath problem but I can't seem to get it to work.
Thanks!
-zood
Posted: 27 Feb 2008, 18:24
by zood
I think I may have solved my own problem
I needed to move the buddy persister (and dependent classes) to another folder on the classpath. Simple enough...
thanks Lapo, and everyone else who helped sort out the original issue here.
Posted: 27 Feb 2008, 23:45
by tobypb
I'm now loading my extension through a .jar specified in the wrapper.conf file. I have removed the javaExtensions directory from wrapper.conf and I have added <AutoReloadExtensions>true</AutoReloadExtensions> to my config.xml. Yet still when I update the jar file I have to restart the server to get it to load the changes, otherwise it uses the version of the jar that were loaded at runtime of the server. Am I doing something wrong or forgotten something? It'd be great not to have to restart the server every time I recompile the jar.
Below is an extract from my config.xml.. please help!
Code: Select all
<Zones>
<Zone name="zoneName" customLogin="true">
<Rooms>
<Room name="Lobby" autoJoin="false" limbo="true" maxUsers="10000"/>
</Rooms>
<Extensions>
<extension name="extName" className="SomePath.ExtensionMain" type="java" />
</Extensions>
<AutoReloadExtensions>true</AutoReloadExtensions>
<DisabledSysActions>
<!-- actions -->
</DisabledSysActions>
<DisabledSysEvents>
<!-- events -->
</DisabledSysEvents>
</Zone>
</Zones>
Posted: 28 Feb 2008, 08:51
by Lapo
The reloader monitors the class files, so I don't think it will work when they are in a jar file. (maybe I am wrong, I will check)
During testing I'd recommend using class files without packaging them in a jar file, if you need dynamic reloading. You can pack them when you are finished and you need to deploy the application.
Posted: 28 Feb 2008, 09:22
by tobypb
I was using class files before, although I didn't have AutoReloadExtensions enabled at that point. But even when using class files if I pressed the reload button in the sfs admin client it didn't reload new class files but kept using the old ones. Admittedly I had the javaExtensions/ folder in the wrapper.conf classpath at that point but when I removed this classpath the server failed to find my extension files. I cannot understand why the reload has not worked for me
Posted: 28 Feb 2008, 16:44
by tobypb
I can't get java extension files to reload in any way without the server having to be restarted. If I use .class files for my java extension they won't reload. If I use a .jar file they won't reload. I've got autoreload in the zone set to true, nothing seems to work.. arghh.
Am I overlooking something simple here?
Posted: 29 May 2008, 07:49
by Lapo
Extension packaged in jar files won't work. Regular class files work correctly, I am using them on a daily bases.
Of course if you make changes to one or more classes that are not the main extension class, the auto-reloader won't notice the change because it only monitors the main extension file. In that case you need to force the reload from the Admin Tool
Posted: 04 Dec 2008, 15:20
by willypow
It appears this issue still exists even after the recent minor Smartfox version update. Here's an official request that this be fixed in the next release.
Posted: 04 Dec 2008, 16:14
by Lapo
Posted: 04 Dec 2008, 17:20
by willypow
Thank you, yes I saw that solution. The question is why should this be necessary? I am hoping this will be resolved in a future release.