I have a working vaadin-8 application. I want to migrate this application to vaadin-23.I have added dependencies related to vaadin-23
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-bom</artifactId>
<version>${vaadin23.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
i am able to create views based on vaadin-23. But the problem is my vaadin-23 views with #Route annotation are not being used. I am not able to hit those urls from the browser. Do I need to create some servlet for vaadin-23 as I did for vaadin-8?
If the application is not using Spring check this example project for step by step migration from Vaadin 8 to Vaadin 14 running both apps at the same time in the same workspace. Scenario with Vaadin 23 should not be different regarding project setup. github.com/TatuLund/migrate-v8-to-v14/tree/master
But if you use Spring Boot, that is most likely the case. Both Vaadin versions require different version of the Spring add-ons, and those in turn define new scopes and there will be a clash.
In such case one can always deploy two different wars either on different context paths or different ports. Naturally you should keep the projects separated and use different IDE instance for each one. But if your requirement is to keep two apps running on the same server, so that it is easy to switch between them, it will work for that purpose.
Related
I'm playing around the idea of a very huge vaadin application, which consists of a skeleton (providing the ui framework) and hundreds of functional units (providing the specific vaadin views).
The main architectural point is to let the skeleton be agnostic about the functional units, so not a single java dependency to a functional unit should be injected into skeleton. Every single functional unit has to be in it's own distinct JAR.
The vaadin container is started by the skeleton-module. It is perfectly possible to build a navigation with all the necessary routes to the functional units (/routeToView001.../routeToView999) without having further details about them.
However, I don't see, how the started vaadin spring boot container would load the java classes from the independent JARs when navigation occurs in browser. Practical attempts failed. Any ideas?
The Spring Boot integration is by default looking for #Route classes within the Java package that contains the #SpringBootApplication class. This can be further configured by passing package names to the #EnableVaadin annotation.
I haven't tested this in practice, but it might be possible to have a multiple #EnableVaadin annotations so that there would be one in each module and through that also provide multiple locations to look for #Route classes from. In that case, the #EnableVaadin class in each module would also have to register itself in the same way as any other #Configuration by using the regular Spring Boot autoconfiguration mechanism.
Another alternative is that you register route classes manually to the application's route registry (accessed using ApplicationRouteRegistry.getInstance(new VaadinServletContext(servletContext))). In that case, you might still need to have at least a dummy #Route in the base module since Vaadin might not automatically enable itself in a Spring Boot environment unless at least one #Route class is discovered in the regular way.
I use Vaadin #JavaScript annotation to load JavaScript files for my application. It works great but I would need different JavaScript loaded for differents builds.
The idea is to have something like these:
#JavaScript("url.from.properties.or.pom")
So for DEV I would get #JavaScript("https://example.com/test/js/embed.js") and for PROD #JavaScript("https://example.com/production/js/embed.js"). The script url value should be taken from application.properties or pom.xml.
I cannot figure out how to do it. I use Vaadin 8 with Maven and Spring Boot. Thank you in advance.
There's no direct support for what you want to do, but I can come up with three different solutions that you could consider.
Register a DependencyFilter that dynamically rewrites the dependency URL from the annotation depending on the situation.
Create separate Java classes for each case (with all the actual functionality in a shared super class). You can then have either runtime logic or use e.g. different Spring configurations to choose exactly which class to use.
Remove the #JavaScript annotation and instead call JavaScript.eval from onAttach to somehow dynamically inject the script you want.
I have a rather monolithic Grails 2 application that I am attempting to upgrade to Grails 3 (specifically 3.2.7) and refactor into a set of plugins - the current app uses various services on Amazon AWS, I want to refactor it so I can more easily switch to Microsoft Azure or OpenStack.
At present, the big app uses various plugins including Spring Security UI, and the app overrides some of the GSP views from the plugin with its own. In the refactored scenario I have the main app (which will implement the AWS-specific bits), depending on a "core" plugin (with the cloud-agnostic functions) which in turn depends on spring-security-ui. The problem I'm having is that when I put my custom auth.gsp view in the "core" plugin rather than in the top-level app, it no longer overrides the s2ui version of the same view. If I copy the "core" plugin's auth.gsp to the same location in the top-level app, it overrides correctly.
In general, if I have app depends-on plugin1 depends-on plugin2, is there a way to ensure that when I run the app, views provided by plugin1 take precedence over the same views provided by plugin2?
The core plugin will need to specify it should be loaded after spring security ui. You can do that with:
def loadAfter = ['springSecurityUi']
This is documented here: http://docs.grails.org/latest/guide/plugins.html#understandingPluginLoadOrder
Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.
I'm writing a Grails app which I'd like 3rd parties to augment at runtime. Ideally they would be able to add a JAR/WAR to the webapp directory which contains new domain, controller and service classes, new views, and other content.
Is there a simple way to do this within grails? Would it be simplest to create a startup script which copies the new classes etc. into the relevant directories and then updates grails.xml and web.xml?
You will be able to do this in version 2 of grails in which plugins will be also OSGI plugins http://jira.codehaus.org/browse/GRAILS/fixforversion/15421
It seems that the Grails plugins will actually fit quite well for this: http://www.grails.org/Understanding+Plugins
A plugin can do just about anything... One thing a plugin cannot do though is modify the web-app/WEB-INF/web.xml or web-app/WEB-INF/applicationContext.xml files. A plugin can participate in web.xml generation, but not modify the file or provide a replacement. A plugin can NEVER change the applicationContext.xml file, but can provide runtime bean definitions