Vaadin #JavaScript for different builds - vaadin

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.

Related

Multi-Module Vaadin project where routed views are located in independent modules

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.

Include more than one filter from existing JAR into a Grails project

I have a Grails project and want to add existing filters from a JAR file.
I used the WebXmlConfig plugin, mentioned in this answer:
How to add filters to a Grails app
and that worked great for a single filter, but I can't figure out how to extend that to more than one filter.
Do I need to change approach and edit the web.xml template directly?
I'd use the pluginator plugin and put the definitions in doWithWebDescriptor just like you would in a plugin - you can add as many elements as you want. It's a slick plugin that lets apps do things that are generally only supported in plugins, like conveniently editing web.xml (although with a seriously weird DSL) and registering custom artifact types.

Overwrite a plugin GSP and Controller within another Plugin

I have a fairly complicated grails plugin dependency structure within my project and I am having problems overriding classes from the security plugin.
My structure is a little something like this:
Web App
|_ Audit Plugin
|_ Spring Security Core Plugin
|_ Security Wrapper Plugin
|_ Audit Plugin
|_ Spring Security Core Plugin
The reason it is like this is audit is shared between some apps which have the security wrapper, and some what don't, which is why it pulls in Security-Core (it needs at least the ability to get the current principal).
Similarly the wrapper is shared between multiple web apps therefore we put it in a plugin. My problem comes after upgrading Spring-Security-Core to version 2.
My wrapper has a customer auth.gsp and LoginController.groovy. In the older version of security this was fine, as the plugin templated those and made them available in the source of the installing plugin.
However now these files are internal to the plugin, and although I know you can override them within the main app, when trying to override them within another plugin I get some bizarre results.
The Spring-Security-Core version of the login page always overrides my custom login page. I cannot get mine to take precedence.
The second problem is that the LoginController.groovy from the Spring-Security-Core plugin sometimes takes precedence over my one from the wrapper. It seems almost random between builds as to which one will be in use.
Is there any correct way to go about making sure my views and controllers take precedence?
OK playing around with things I found a solution that seems to work for me:
Firstly I couldn't change the order in which the plugins load because the security wrapper does a lot with spring beans and it has to load after the core plugin for this to work. So after a bit of digging in the (DefaultSecurityConfig.groovy) I noticed that you can set the following properties:
grails.plugin.springsecurity.failureHandler.defaultFailureUrl = '/login/authfail? login_error=1'
grails.plugin.springsecurity.failureHandler.ajaxAuthFailUrl = '/login/authfail?ajax=true'
grails.plugin.springsecurity.auth.loginFormUrl = '/login/auth'
So I created a custom controller and login page which have a different name to the ones use in the core plugin and changed these properties to point to my locations.
To neaten this up, in the UrlMappings for the wrapper (named: SecWrapperUrlMappings) I put a mapping from /login/** to /seclogin/**.
Make sure that these new locations aren't locked down so that people can access them and that seems to work well. I now reliable know, whichever order they load in my login page and login controller are used.
In Grails-4.013 and spring-security-core-4.0.4, I did the following trick.
In my custom plugin instead of LoginController and LogoutController I named them as SigninController and SignoutController respectively. And in UrlMappings.groovy of App mapped them like..
static mappings = {
"/login/$action?"(controller: "signin")
"/logout/$action?"(controller: "signout")
....
....
}

Customising Jenkins' appearance to make it easier to tell instances apart

I am responsible for four different Jenkins installations - two test and two production servers.
What options do I have from within Jenkins to make it more obvious which machine I am connected to?
What I would like to do is be able to change the Jenkins text at the top of the screen to 'Jenkins Department 1 Test' - is this possible? Are there other options such as changing colours etc?
I think the simplest way to do this is with the Simple Theme Plugin.
A plugin for Jenkins that supports custom CSS & JavaScript.
You can make your own simple css and/or javascript, point to the file in the configuration and you're done. Or you can use existing css from the internet.
obsolete as of 2017
Try the Page Markup Plugin.
Adds custom HTML content to header & footer on all Hudson pages.
Use this plugin to add your own custom content (e.g. CSS, site headers, and site footers) to Hudson pages.
I haven't used this plugin myself, but you should be able to override the default CSS styles to insert your own header text or image.
Alternatively, you can edit the CSS / images yourself in JENKINS_HOME/war/css and JENKINS_HOME/war/images, but I don't recommend that since you'll probably lose any customizations when you upgrade.
Another possibility would be to use tools like Greasemonkey (Firefox) or a similar built in ability with in Chrome (http://www.chromium.org/developers/design-documents/user-scripts) to have JavaScript code alter the appearance of the page. You'd get a lot of flexibility and could potentially go so far as to prohibit certain commands from executing or enforce additional restrictions when executing certain commands on the production servers.
In addition to or instead of the Simple Theme Plugin proposed by #Illidanek, you might also try the jQuery Plugin.
This plugin is a library plugin for other plugins to share common jQuery. It also allows users to use jQuery on each view descriptions.
It doesn't completely match your requirements, but it might be useful to add jQuery snippets for special formatting/styling/html-manipulation in the Jenkins "System Message", in view descriptions or in job descriptions.
I personally often prefer the Simple Theme Plugin.

Is it possible to add Grails MVC classes at deployment time?

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

Resources