Running multiple servers with different functionality, is outside the scope of the Spring Boot + GWT archetype.
Spring Boot + GWT archetype gives you one server codeline, Ie: One WAR or JAR. You can can replicate and load balance it nicely (I do this with this architecture in the Google Cloud). I suspect this is actually what you want. However, If you really want to run multiple servers that have different functionality (Ie: Create multiple different WARs or JARs), you'll need to create your own services. How you do this is up to you, but the Spring Boot + GWT archetype will be able to call these services no problem. On Monday 30 September 2024 at 11:09:30 pm UTC+10 [email protected] wrote: > Hi FRANK, > > We have gone through the link provided by you "Spring Boot + GWT > archetype: https://github.com/NaluKit/gwt-maven-springboot-archetype"; > > We want to host client on different server-machine and server will be > hosted on another server-machine. We cannot find how will we achive the > same with the architecture provided above. > > > > On Friday, September 27, 2024 at 1:55:26 PM UTC+5:30 Frank Hossfeld wrote: > >> Regarding point 7: >> In addition to what Jens said, here you'll find an artifact creator for a >> Spring Boot + GWT archetype: >> https://github.com/NaluKit/gwt-maven-springboot-archetype >> >> Also, I would like to add: >> to prepare the project, running 'mvn clean compile' is all you need to >> do to prepare the project for testing. >> After the 'mvn clean compile' command is executed, start the codeserver >> and wait until you see the URL of the codeserver in the terminal window! >> After the URL is printed, the Spring Boot application can be started. This >> is necessary, because the codeserver has to create the launcherDir before >> Spring Boot is startet. Otherwise Spring Boot will not publish the content >> of the launcherDir and the project will not work. >> >> Jens schrieb am Donnerstag, 26. September 2024 um 18:49:22 UTC+2: >> >>> Now! our WAR is compiling (single permutation) in 10.25 mins only. We >>> are testing our application workflow as many of the differedJS files are >>> greater than 1 mb. We'll try to reduce the size. >>> >>> >>> Sounds way better and you can likely decrease the required Java heap now >>> as well. You had A LOT of split points. Personally I use split points more >>> like one per menu item of the first or second level menu, depending on the >>> size of the application. Grouping menu items behind a single split point >>> can also make sense, e.g. user vs. admin menu items or based on other usage >>> patterns. Occasionally I use split points for a feature like rendering >>> charts that could be split away until needed. >>> >>> >>> >>> Whereas GWT 2.6.1 upgradation is concerned, we would like to say, yes! >>> we are actively developing the application and are intrested in upgrading >>> GWT 2.6.1. But there are some issues which are required to be addressed. >>> Many time earlier we have planned the upgradation, but dropped the idea due >>> to not having the clear answers on bellow mentioned points. >>> >>> *1.* Which version of GWT we should move to? As many of the latest >>> technologies are rolling arround and GWT in itself also have released many >>> versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a >>> huge application rapidly is not possible, so we want to be very sure. >>> >>> >>> The newest GWT 2.11 version will be fine. It still supports running on >>> Java 8 but future versions will likely not. >>> >>> >>> >>> *2.* We are using "Apache Netbeans IDE" from a long time and now the >>> team is also very much famlier with it. Upgraded GWT4NB plugin was missing >>> from market place. Can we go for upgradation without changing IDE? >>> >>> >>> I don't know about Netbeans and GWT4NB. However GWT SDK itself hasn't >>> changed in structure so I don't see why GWT4NB shouldn't work anymore with >>> newer GWT versions. Of course you can use GWT without any IDE plugin and >>> launch GWT SuperDevMode and GWT Compile via ANT for example. Of course you >>> would loose all benefits the IDE plugin gave you. >>> >>> >>> *3.* We are using "JDK 1.8". Do we required to upgrade JDK too? >>> >>> >>> No, as of now. But future versions will require newer JDK. If you >>> upgrade your libraries then you can probably pretty easily upgrade JDK as >>> well. You might need to add some libraries as some classes have been >>> removed from JDK 11, see: >>> https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8190378 >>> >>> >>> *4.* We are using "PAYARA-WEB-SERVER" in both development + Production >>> environment. GWT upgraded versions are comming with inbuild JETTY servers. >>> Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have >>> to stick wit JETTY only? >>> >>> >>> GWT ships with Jetty for convenience to get a demo app up and running >>> quickly. But these days we recommend using your own servlet container and >>> it can be any servlet container you like. If you do not use any servlet >>> specific features of GWT like GWT-RPC or RequestFactory then you can use >>> whatever server you like. PAYARA should continue to work fine. >>> >>> >>> >>> *5.* We are using "ANT build" not "Maven build" means we are not having >>> any type of POM files. >>> >>> >>> Then you likely have a project or a folder with all your dependencies. >>> You can download GWT from gwtproject.org, unzip it and use these jars >>> in your ANT file. Alternatively there are ANT tasks provided by Maven which >>> allows ANT to download dependencies based on POM files. See: >>> https://maven.apache.org/resolver-ant-tasks/ >>> >>> >>> >>> *6.* We are using sencha (gxt 3.1.1) mainly for GRID functionality. >>> Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT >>> is paid. What are its alternative? >>> >>> >>> That is probably the main issue to solve. There are some UI widget >>> libraries for GWT like https://dominokit.com/solutions/domino-ui/v2 but >>> if you switch the library you would need to rewrite your code of course. >>> >>> Maybe you can make GXT work by patching it yourself if allowed. >>> >>> >>> >>> *7.* Our application is having GWT standard architecure eg: (client + >>> shared + server) in the same application. We want to split our application >>> as client & server seperate. Where we want to move server part in >>> SPRING-BOOT without any major changes. Is it possible? >>> >>> >>> Sure. First split your application without using spring boot and make it >>> run again. Then apply spring boot to your server project. GWT 2.11 also has >>> a JakartaEE variant now so Spring Boot 3+ should work as well (but requires >>> Java 17). The benefit of splitting your project into three is that you can >>> also use different JDK versions for client and server projects. Sometimes >>> that is useful if your server has JDK requirements that are either newer or >>> older than what you want to use for the client. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f044fe49-4d57-4c9d-8b0e-f2df84ae2d3an%40googlegroups.com.
