I notice that the demo app for Scaladin 3.0 uses vaadin.scala.ScaladinServlet for the servlet class instead of the regular java version.
Browsing the source, I did not see the equivalent wrapper for the Vaadin portlet.
Going forward, what should the strategy be for using Scaladin 3.0 apps as portlets?
A.) Deploy as a ScaladinServlet in web.xml, and then use Portlet spec 1.0 to point to that servlet?
or
B.) Expect a ScaladinPortlet wrapper class eventually, allowing deployment as a Portlet 2.0 based app, eliminating the need for web.xml files and servlet deployments
I just committed
vaadin.scala.ScaladinPortlet . I didn’t test it on a portal so I don’t if it works. But you could try if option B is possible with that.
“failed to load the bootstrap javascript /html/VAADIN/vaadinbootstrap.js”
I am running on Vignette Portal 8.2, which is on Tomcat6. There are no Vaadin jars installed directly into shared lib dirs.
It appears this is due to my not installing the VAADIN files for static serving, as I want, and have been, just including the vaadin lib jars within the war file’s /WEB-INF/lib directory. I tried my very simple UI using the ScaladinServlet, and it works. I suspect this is due to the fact that the servlet includes a mapping to use the VAADIN files from the war. Here is a clip from the working ScaladinServlet UI usage, and the failing ScaladinPortlet UI attempt.
So no way to avoid that step (perhaps by some config setting), as there was in Vaadin 6 by using Portlet 1.0 referring to servlets which had the mapping for the /VAADIN/* url?
I use SBT for building, and can upgrade Vaadin now by simply changing the version number I want. If I now have to extract multiple dirs, and update every portal it is deployed to, that is a bit of a step backwards.
Perhaps simply making a VAADIN dir under the src/main/webapp SBT dir, copying the files extracted from the three vaadin library jars (as referenced in the link you provided), and allowing them to be packaged into the .war file? They should be accessible then under ./VAADIN/* from the apps view, though, not the /html/VAADIN/* it appears to be looking for. Could this be made to work with a setting to have vaadin look in its own web app root folder, instead of the root of the web-server the portal is running on?
I was able handle the “static” javascript/css serving by extracting the VAADIN dirs out of the jars (per the article you provided the link to), and including that dir in the root of the .WAR file. This was extracted by tomcat upon deployment, and I simply made a symlink at webapps/ROOT to point from html to …/myproj/, and the VAADIN dir extracted there was then found.
If there was a way to not have /html/ hard-coded as the root of the path to find the VAADIN dir, I could use a combination of a servlet that serves files in some dir in lib jars (in the war file), and this setting, to not have to go to the tomcat server and create a symlink. The deploy would work properly without any added install. Is there such a setting to change the path for the VAADIN files from /html/VAADIN/ to something else? (./VAADIN?)
I receive these two items in the tomcat stderr log when using the ScaladinPortlet:
Mar 01, 2013 1:51:23 PM com.vaadin.server.AbstractCommunicationManager getBrowserDetailsUI
WARNING: There is no window.name available for UI class vaadin.scala.internal.WrappedVaadinshoulUI that should be preserved.
Mar 01, 2013 1:51:28 PM com.vaadin.server.VaadinPortlet serveStaticResources
INFO: Requested resource [APP]
could not be found
I suspect the second may have something to do with what I’ve been asking about regarding serving the static Vaadin resources.
1.) What, if anything, should I be doing differently regarding the no window.name warning. The Scaladin class referenced is internal.
2.) What does [APP]
refer to? How should this be corrected?