France
Joined: Feb 6, 2024
Post Count: 19
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
I think I'm narrowing in the problem. The URL are not really a problem, I set the external URLs for the JavaScript interaction in the index.jsp and I set internal URLs for the call to the backend classes (ServerUserPreferences and HomeRecorder) the problem is the session. You store the reference to the file being opened in a session variable. I see that behind the proxy, the sessionid is renewed at every call and the session variable is destroyed, so the WriteHomeEdits script assumes that the Home file was never opened in the first place. I will explore the possibility to create a custom session manager......
France
Joined: Nov 7, 2005
Post Count: 9181
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
You may use application instead of session in readHome.jsp, writeHomeEdits.jsp and closeHome.jsp. It's used to store the reference copy of the edited file, so there's no risk that some conflicts happen here. But if there's more than a user in your application, you'll have to manage session somewhere in case you don't want a user to edit the files of other users.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
France
Joined: Feb 6, 2024
Post Count: 19
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
Hello Emmanuel, thanks it is a good idea, of course it would be more elegant to have a custom session, but this would take a serious amount of effort. Nevertheless by putting application instead of session, I'm back to my previous issue. There is something in this code that brings up to javascripts the URLs:
serverUserPreferences = new ServerUserPreferences( new URL [] {new URL(localBaseUrl, "lib/resources/DefaultFurnitureCatalog.json")}, localBaseUrl, new URL [] {new URL(localBaseUrl, "lib/resources/DefaultTexturesCatalog.json")}, localBaseUrl); getServletContext().setAttribute("serverUserPreferences", serverUserPreferences);
This is where there is a mix of server bound calls and client bounds calls that are using the newly crafted URLs. If I use server URLs (http://localhost....) the server classes are working fine but they somehow pass on the URL to Javascript, in the console I see this error message:
Failed to load resource: net::ERR_CONNECTION_REFUSED
which is normal because the client do not "see" localhost.
If I use the regular URLs (http://PROXY_IP/PROXY_CONTEXT, the server classes will fail because they do not "see" the proxy.
So the classes that you have created to support SH3DJS are breaking proxy compatibility.
Sorry for the long post and thanks again for dedicating some time to my idea.....
France
Joined: Nov 7, 2005
Post Count: 9181
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
In your case, you should set serverUserPreferences to null. User preferences on server side are useful to reduce the size of the saved SH3D file, by replacing the furniture and textures stored in a SH3D file by URLs if they exist in the preferences catalogs too. This is the case in HomeTest.sh3d where you'll see that the size is smaller after the first call to writeHomeEdits.jsp, because it contains some furniture of the default catalogs (but also some furniture and textures not found in it). But keeping a larger SH3D file on the server is not an issue, it will be just more data to send to the client when reading the home it contains. Anyway, if the designed home is built from scratch on the server which is probably what you want to propose, the Home.xml entry in its SH3D file will contain only URLs and will be as small as possible.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
France
Joined: Feb 6, 2024
Post Count: 19
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
Ok, yes the purpose is to get rid of the Fat Java client for the card users in Home Assistant; I do not see as a big problem to have bigger SH3D files (even though the load will be slower as no furniture library can be cached in the browser). On the other hand I need to enlarge the default Furniture Catalog otherwise users will always need to do the first Home build in the Fat Java Client. I did not get your comment on Home.xml but I am still learning on the architecture of SH3D.....
France
Joined: Nov 7, 2005
Post Count: 9181
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
A SH3D file is actually a ZIP file containing texture images, furniture 3D models and icons, as well as an entry named Home.xml which describes the designed home respecting this DTD. If you look at an example of Home.xml, you'll see that the model, icon and image attributes are equal to a number matching another entry in the SH3D file or a URL matching data on the server.
You'll find here instructions about how to add more furniture and textures libraries to the catalogs using the tool PropertiesToJson. Note that you can obtain also a JSON version of an existing SH3F or SH3T library file with the version 2.0 of the Furniture Library Editor and Textures Library Editor if you save it as a file ending by .json. This is easier than using PropertiesToJson but you'll probably have to change furnitureResourcesURLBase and texturesResourcesURLBase in application configuration (or adapt the relative URLs of icon#, model# and image# properties in generated JSON files).
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
France
Joined: Feb 6, 2024
Post Count: 19
Status:
Offline
Re: SweetHome3DJS - Porting plugin - ARM architecture support
Hello Emmanuel, I do not know if it is related, but according to your description, probably yes. By putting the ServerUserPreference to null, it works (even behind the proxy), but, the performances to load a complex model (10-20Mb) are seriously degraded. In fact your idea to have the furniture managed with independent files is very efficient and takes advantage of the browser cache. I wonder if you can think of a way (in your next releases) to have the serverUserPreferences to work well behing a proxy, by separating the backend URLs and the frontend-URLs. Maybe it is already the case as the Server class accepts 2 couples of URLs, but I could not figure it out
