Besides that the plugin does not provide this functionality - as Greg already mentioned - you will run into security issues, while hosting the client on one server and the server part on another (CORS). (OK, you might find a workaround with some fanzy server configuration, but it's risky) If you really want to do this, you can use the artifact as designed and use the server module of your client service as proxy that calls the other server. In this case you can use the artifact as designed and there is no need for disabling CORS and so.
Craig Mitchell schrieb am Dienstag, 1. Oktober 2024 um 02:51:40 UTC+2: > 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/d0719f12-d008-4035-98aa-9027a7add0b4n%40googlegroups.com.
