I've seen the request to host static webcontent (i.e. html/css/js) on a separate server many times before. Especially with dedicated infrastructure teams. The trick is to have mvn build a separate jar with only the static content and unzip that on the target webserver. It's been a while since I last did this though.
Still I'm quite interested why we've never run in similar compilation issues despite having quite a larger set of frontend code as stated in this thread. Can someone explain? I expect it might have something to do with the fact we only use a single RPC call? The RPC is used as transport only for a command pattern implementation of the communication between front and backend. The Rpc basically implements a CommandSink in the UI code and a CommandSource on the server. Hence we always only needed a single rpc. Op dinsdag 1 oktober 2024 om 06:48:50 UTC+2 schreef Frank Hossfeld: > 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/89a9b0ad-be73-4751-ada2-05922eec600cn%40googlegroups.com.
