Hi there,
I wrote a couple servlets and wanted it to interact with the extension code I wrote (the goal is to provide some web services), but now I'm stuck at class loading.
I put my extension code at SFS2X\{extension}\xxx.jar, which Jetty does not load, so when it processes the web.xml file I deploy in www folder it throws exception.
It seems that Jetty would only load classes from WEB-INF folder (at SFS server startup, before extensions are loaded), but if I deploy my code to both directories, because they're loaded by different class loaders, they are considered different classes so my servlet code still cannot run.
In SFS1.6.6 this problem did not exist - class files put into javaExtension folder would be accessible by Jetty automatically. I've tried different ways in SFS2X but still could not get it running, can you give me some guidelines how to do it?
Thanks!
Jetty and extension code
I think it is possible to interact with extensions in a simple way, by working with the top level interfaces.
For example the top level interface of an extension is:
com.smartfoxserver.v2.extensions.ISFSExtension
The interface exposes this generic method:
which allows to send generic "requests" tp any extension.
Your servlet can access the main SmartFoxServer instance, from there you can grab the ZoneManager via getZoneManager()
Then you can obtain the Zone that you want and finally its Extension.
An IDE (Eclipse/Netbeans) will guide you via code autocomplete.
Let us know how it goes.
For example the top level interface of an extension is:
com.smartfoxserver.v2.extensions.ISFSExtension
The interface exposes this generic method:
Code: Select all
Object handleInternalMessage(String cmdName, Object params);
which allows to send generic "requests" tp any extension.
Your servlet can access the main SmartFoxServer instance, from there you can grab the ZoneManager via getZoneManager()
Then you can obtain the Zone that you want and finally its Extension.
An IDE (Eclipse/Netbeans) will guide you via code autocomplete.
Let us know how it goes.
I'm not sure i this is what you're looking for, but from my jython servlet i simply access the extension via:
from there i can access all public methods in the extension. Jetty itself doesn't need to load the extension jar, SFS2X loads it.
Code: Select all
myExtension = SmartFoxServer.getInstance().getZoneManager().getZoneByName("myExtensionName").getExtension()
from there i can access all public methods in the extension. Jetty itself doesn't need to load the extension jar, SFS2X loads it.
Well first of all thank you for your help, it does solve the problem somehow, because the handleInternalMessage() thing can indeed serve this purpose. (By the way, is this method called internally by SFS server? I don't want to mess up with that part by overriding it.)
No, never called. It is a utility method for sending "commands" to an extension from another object, for interoperability. Feel free to override.
Still I have to say this approach is kind of a pain, due to the class file incompatibility issues.... I put the core business logic at the extension (including all the entities), and just a generic servlet at Jetty. The thing is, they still cannot share *any* of the libraries that was written for the extension, even some utility libraries. In order to get it working, I'll have to discard a lot of code written for 1.6.6 if I need to upgrade (to take advantage of the UDP protocol).
There are ways around this. It's a matter of organizing the code.
My advice is to separate your business logic interfaces from their implementations.
Then you deploy the interfaces at the top level of the Classloading structure of SFS2X. This means that you create a jar file with the interfaces and deploy it to --> SFS2X/lib/
The implementations can be deployed at the Extension level. This way your servlet is able to work with the interfaces.
Is there any chance that we can have the Jetty dynamically add the extension jars into its classpath as well? That would be super helpful. Thanks!
No, not possible. Sorry
hope it helps
LOL I guess my previous post was meant to be replied but it got edited instead, looking like I'm answering my own question.
Yes creating interfaces and place them in common library will help the problem, but then in this case we're still somehow deploying game-specific logic there, and in fact, it's not too different from placing the business logic (the real extension code) there - albeit the advantage of hot deployment.
Since in my use case I'm only using SFS2X to serve one game, one extension only, I ended up placing all the jar files into extensions\__lib__\, and since those jars are loaded at startup time Jetty could access them with no problems.
The only small trick I had to do - since SFS2X server requires some jar files located in extensions\{my extension}\ folder or it throws an exception, I placed a dummy jar file that only contains a text file within it. Maybe you can consider moving that check away - as long as you're able to read the extension class file specified in the zone config.
Still, thanks a bunch!
Yes creating interfaces and place them in common library will help the problem, but then in this case we're still somehow deploying game-specific logic there, and in fact, it's not too different from placing the business logic (the real extension code) there - albeit the advantage of hot deployment.
Since in my use case I'm only using SFS2X to serve one game, one extension only, I ended up placing all the jar files into extensions\__lib__\, and since those jars are loaded at startup time Jetty could access them with no problems.
The only small trick I had to do - since SFS2X server requires some jar files located in extensions\{my extension}\ folder or it throws an exception, I placed a dummy jar file that only contains a text file within it. Maybe you can consider moving that check away - as long as you're able to read the extension class file specified in the zone config.
Still, thanks a bunch!
jetty problem with servlet
Hi Guys,
I am trying to do something similar, actually very similar to what the reply from lapo and dingo said to do, but I am having a hard time with Jetty itself for some reason.
I put a .war file in the SFS2X/www/ which should be able to access a zone's extension as described here, but I actually get a Jetty problem with the JSP.
HTTP ERROR 500
Problem accessing /sfsinvoker/index.jsp. Reason:
JSP support not configured
now, sfsinvoker is the .war file in ./www (so I have no idea why index.jsp is referred to in the error) but in any case, i've looked at config files and compared them with a jetty config on sfs1.6.9 (where this works fine) and I can't figure out what is wrong here.
(of course the servlet has been upgraded to SFS2X and its jetty servlet-api library)
FYI - I am using SFS2Xrc2
any ideas?
I am trying to do something similar, actually very similar to what the reply from lapo and dingo said to do, but I am having a hard time with Jetty itself for some reason.
I put a .war file in the SFS2X/www/ which should be able to access a zone's extension as described here, but I actually get a Jetty problem with the JSP.
HTTP ERROR 500
Problem accessing /sfsinvoker/index.jsp. Reason:
JSP support not configured
now, sfsinvoker is the .war file in ./www (so I have no idea why index.jsp is referred to in the error) but in any case, i've looked at config files and compared them with a jetty config on sfs1.6.9 (where this works fine) and I can't figure out what is wrong here.
(of course the servlet has been upgraded to SFS2X and its jetty servlet-api library)
FYI - I am using SFS2Xrc2
any ideas?
That sounds like a JSP problem.
Can you try with just code? I mean only Java code with not JSP tags?
At least this will confirm where the problem is ... SFS vs JSP compilation and from there we can see how to solve the issue.
Also, make sure to take a look at the http logs (logs/http) for more details on the problem.
Can you try with just code? I mean only Java code with not JSP tags?
At least this will confirm where the problem is ... SFS vs JSP compilation and from there we can see how to solve the issue.
Also, make sure to take a look at the http logs (logs/http) for more details on the problem.
Who is online
Users browsing this forum: No registered users and 128 guests