forums.smartfoxserver.com

It seems that SFSPRO_1_5_windows.exe installer does not install the smartfoxserver.jar file.

yes, that's correct.
The library layout changed a little in the latest version.
If you need to compile java classes, point your classpath (or java editor classpath) to the lib/jysfs.jar file.

Lapo wrote:yes, that's correct.
The library layout changed a little in the latest version.
If you need to compile java classes, point your classpath (or java editor classpath) to the lib/jysfs.jar file.

Given that this change could break older setups, is there a reason that it was omitted from releaseNotes.txt and other documentation on changes from 1.4? Nor is the new jar file mentioned in any example for the server-side Java API.

Furthermore, if smartfoxserver.jar is no longer used, why does the Windows installer for 1.5 not remove smartfoxserver.jar from the previous installation? It is detrimental to users of the newer version if a deprecated jar file is silently left in place.

Given that this change could break older setups, is there a reason that it was omitted from releaseNotes.txt and other documentation on changes from 1.4? Nor is the new jar file mentioned in any example for the server-side Java API.

Sorry for the inconvenience, it should have been reported in the release notes.

Furthermore, if smartfoxserver.jar is no longer used, why does the Windows installer for 1.5 not remove smartfoxserver.jar from the previous installation? It is detrimental to users of the newer version if a deprecated jar file is silently left in place.

The 1.5.0 installer does not touch any of the older files. It installs in its own folder so that you can still use any other previous versions.

I can no longer compile using this new .jar.

I get this error when using sendResponse():

All my java extensions compile and run without errors using the old smartfoxserver.jar.

Are there any potential problems reverting back?

Thanks.

When compile add in your class path also and json.jar ( from lib directory)
example:
.../javac -classpath "../lib/json.jar;../lib/jysfs.jar" Example.java

exactly! it just seem that you don't have the json package added to your classpath

Lapo wrote:exactly! it just seem that you don't have the json package added to your classpath

I get the same problem. I am not using the json package in any of our code, thus we should not have to include it in our classpath. The problem is caused by the fact that classes in jysfs.jar link to the json package without including the necessary class files in jysfs.jar.

This is a bug. The SF classes in jysfs.jar should either not link to json, or should include the class file linked to.

This is a bug. The SF classes in jysfs.jar should either not link to json, or should include the class file linked to.

It's a dependency issue, not a bug
(A bug is a programming error that prevents the software from working as expected.)

We'll provide better documentation about library dependencies but it's not a good idea to include them inside our packages. (Libraries are created to be standalone units of code, encapsulating them inside other libraries would break this concept)

Lapo wrote:(Libraries are created to be standalone units of code, encapsulating them inside other libraries would break this concept)

So does linking to them in jysfs.jar without adding it to the class-path of jysfs.jar. It breaks our ability to compile without tracking down SF dependencies that our code doesn't use. The point of an API is to hide the internals, not force us to hunt them down.

Any of these are adequate solutions:
1) Including a copy of the particular class file inside jysfs.jar
2) Writing a wrapper class for the json class so that the json package stays internal use only
3) Adding the json jar file to the class-path in the manifest of jysfs.jar

The 3rd solution is obviously the cleanest and most recommended by java experts. That way you don't force developers to make links to SF's dependencies which they themselves are not using. And yes that IS a bug, because breaking existing code solutions without documentation is always considered a bug, and the packaging/manifest are part of the programmer's responsibility.

In any of these cases, the json object documentation should be included along with SF documentation if you expect people to use it. An undocumented API is the same as a broken API.

Sorry for oftopic
http://www.projectcartoon.com/cartoon/2/

ok, no prob. It's funny
dunno, if it's also meant to be sarcastic. In such case please post your comments, it's definitely much more helpful for us

We have added a new article to the online docs about Java extension development --> http://forums.smartfoxserver.com/viewtopic.php?t=1187

hope it helps