|
| Re: Scout application in single war [message #1848565 is a reply to message #1848554] |
Wed, 08 December 2021 08:41   |
|
Yes, this is possible, although not very well documented.
You need a module with these dependencies:
- Everything from the *.ui.html.app.war module
- Everything from the *.server.app.war module
- One additional module: org.eclipse.scout.rt.serverbridge
You can either use the existing *.ui.html.app.war module and extend it or create a copy of it under a new name (e.g. *.all.app.war). Because resources can only exist once, you have to merge files such as config.properties or logback.xml.
There is an example in the Scout contacts demo app, although only for the development mode (but the production module should be quite similar).
How does it work? The serverbridge module installs a bean decorator that simply replaces the HTTP service tunnel for all beans annotated with @TunnelToServer by direct calls to the implementation. Everything else works just the same, i.e. you still have a client session and a server session with run contexts, transactions etc.
Regards,
Beat
|
|
|
|
| Re: Scout application in single war [message #1848900 is a reply to message #1848610] |
Wed, 22 December 2021 16:43 |
 Seydou Zakou
Messages: 44
Registered: May 2020 |
Member |
|
|
I were able to combine the 2 parts of the application into a single war, but it Seems that ClientSession and ServerSession are having problem with the setup.
After deployment into tomcat, call to ClientSession.get().getUserId()
org.eclipse.scout.rt.shared.session.Sessions - Session not of the expected type [session=com.groupesepro.bp.core.client.ClientS
ession@4e1ebf2f[id = ernoft2tisrth6328ocl7avbm8s4etjnbkhf2dplk9tn3bu0ds6], expectedType=interface org.eclipse.scout.rt.server.IServerSession]
Is there some case where combining of the 2 parts of the application in single war is not recommended ? Or what should be care about when someone plan to have a single war ?
[Updated on: Wed, 22 December 2021 16:49] Report message to a moderator |
|
|
| Re: Scout application in single war [message #1848901 is a reply to message #1848900] |
Wed, 22 December 2021 17:33 |
|
Looks like you are mixing "client" and "server" code.
Even if you deploy both parts in a single war (with the additional serverbridge module, as described above), the presentation layer (forms, outlines etc.) and the service/persistence layer are still separated. The run context determines in which "world" your code is running. The only way to switch between them is by calling a service with @TunnelToServer annotation. Only with in this tunnel Scout automatically convert the client context to a server context for you. The serverbridge does not remove this tunnel, it will only make it very thin (in-memory calls instead of HTTP).
You can have a look at the contacts demo application. If you start the application from the module org.eclipse.scout.contacts.all.app.dev (instead of org.eclipse.scout.contacts.server.app.dev and org.eclipse.scout.contacts.ui.html.app.dev), you can see it in action and compare it with your setup.
Regards,
Beat
|
|
|
|
| Re: Scout application in single war [message #1848964 is a reply to message #1848937] |
Mon, 27 December 2021 10:05 |
|
The message "Session not of the expected type" you posted earlier suggests that you do somehow call server code from within a client context. Unfortunately, the debug log does not help, and it does not contain the method "execLoadPermission" you mentioned.
A point you have to keep in mind: When you put the client and server code in the same application, all of the bean classes are on the same class path. This means that when resolving an instance for an interface, you might get a different implementation than before. Example: assume there is an interface IFoo in the shared module, a ClientFoo implementation in the client module and a ServerFoo implementation in the server module. Naturally BEANS.get(IFoo.class) can only return one of the the implementations. If there are two WAR files, each part of the application only contains one implementation. But when merged, the bean manager will choose one of them. This can lead to errors when the implementation does not support this situation correcly. So if ServerFoo calls Sessions.currentSession(IServerSession.class), this may fail when called from within a client context. To fix it, you need an implementation that can handle both cases, e.g. "if (ISession.CURRENT.get() instanceof IClientSession) { ... }".
Long story short: If you need class isolation, stick to the setup with two separate WAR files (both application can't "see" each other). When deployed in a single WAR file, the bean implementations might have to be adjusted to work with different runtime contexts.
Regards,
Beat
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03906 seconds
] 
Search
Help
Register
Login
Home
