I'm developing a Spring application which needs to support pluggable modules - add the JAR to the classpath and it will automatically find and load the module's Spring application context XML. This part is already working.
The problem right now is figuring out a way for the modules to provide custom JSP pages. Each module will require a configuration page, which contains form fields specific to that module.
How can I use Spring MVC to implement such pluggable pages? It should work something like so, that the module's JAR file contains the configuration page (as JSP) and its Spring MVC controller, which the surrounding application will then include into the rest of the application (maybe as a JSP fragment inside the application's page template).
If this cannot be done with Spring MVC and JSP, then what would be a good alternative?
Try adding a ResourceBundleViewResolver config to each pluggable module (not sure if having multiple resolvers will work or not, but it allows you to define views via the classpath, not specific locations. See http://static.springsource.org/spring/docs/current/reference/view.html.
If having multiple resolvers in your modules don't work, then try ResourceBundleViewResolver in the main app config, and then have all pluggable modules follow the same view location setup internally to the JARs.
Related
I would like to customize the spring boot admin ui to put some custom urls for healthcheck.I didn't find any examples on altering the UI like adding some tabs or putting some urls etx.
I found some documentation under http://codecentric.github.io/spring-boot-admin/current/ but it wasn't helpfull.
Any help on this would be really appreciated
Spring boot admin uses vue.js for frontend.
It is possible to add custom views to the ui. The views must be implemented as Vue.js components.
The JavaScript-Bundle and CSS-Stylesheet must be placed on the classpath at /META-INF/spring-boot-admin-server-ui/extensions/{name}/ so the server can pick them up. The spring-boot-admin-sample-custom-ui module contains a sample which has the necessary maven setup to build such a module.
The custom extension registers itself by calling SBA.use() and need to expose a install() function, which is called by the ui when setting up the routes. The install() function receives the following parameters in order to register views and/or callbacks:
I need to add some behavior to all my portlets.
It must be some ajax query that check some condition and if it is true - show message.
At the first I decided to add some html to my portal skin for my applications. In this html I add js-script to make ajax query. But I don't know the context, to send query, because we use WSRP to access our portlets. Thats why I cannot get WSRP context and make query.
Second thought was to add common jsp in all portlets, and in this jsp make logic (from jsp I can get context). But it is not good if I will change all portlets jsp (using tag "include").
So my questions next:
How to add behavior to all portlets?
How to get WSRP context in JS?
How to add jsp to all portlets, without changing portlets jsp?
P.S. And I cannot touch portal's theme, anyway.
You should be able to use a global portlet filter for this in WebSphere Portal. You create a WAR module with the filter class in it, and deploy it to the application server on which WPS is running. It must have a file called plugin.xml in WEB-INF which describes your global filter(s) via eclipse plug point mechanisms within Portal. Your class must implement any of the sub-types of javax.portlet.filter.PortletFilter standard interfaces, meaning the code you write is standards based.
If you implement a global portlet filter, you must understand that it will be invoked for every portlet invoked on the portal - including administrative ones. To avoid running your intended logic where you do not wish to do so, check the context path of each request.
From the WPS Knowledge Center article:
Because global portlet filters affect all portlets running in the
given portlet container, the console modules that are contained in the
Integrated Solutions Console are also filtered. It is important to
test your filter implementation for undesired side effects on console
modules or portlets. One approach is to test by checking the context
path of the request in your filter logic.
I don't know the context path of the WSRP portlet off top of my head, but some SystemOut logging should help you identify what this value is and point you in the right direction.
Lastly, there is an article with sample code describing the technique on the portal wiki.
We have several in-house developed application in Groovy/Grails and use a shared plugin containing code that is common to all applications. We're needing more advanced authentication (LDAP, CAS, etc.) so it's time to implement the Spring Security plugin. I've been doing a bunch of reading on it, but I'm stuck at something as simple as changing the URLs and GSP pages that are used for the login and logout. I'm assuming that we'll also need a custom controller to make these changes.
In a normal situation where an application is using the Spring Security plugin, changing the default controller and/or GSPs seems to be as easy as just creating a file with the same name and location as the original files (since application files override plugin files). However, we're including the Spring Security plugin in our shared plugin which then is included in the application ... so unless it's possible to have one plugin override another plugins files this sort of solution doesn't seem to work here.
What would be the correct approach for overriding the default login/logout pages, url, and possibly controllers being used?
The controllers and GSPs are part of the plugin in 2.0. If you want to customize them copy them from the installed plugin directory to your project in the same folders and make the changes there. App files always override plugin files because the plugins are compiled first, then the app, so the app's files take precedence.
This procedure worked successfully for me.
I have spring MVC application where in I will be loading the multiple components (jars) in run time. Each component can create its own topic/queue. I also need to build a special integration route (including channel and other components) when I load the new component. And delete the route when I remove the component. I was thinking dynamically generating a spring xml file with routes and load into container. Is this possible or do I have any better alternatives
The dynamic-ftp sample uses that technique...
It uses the Spring 3 environment feature to pass in properties to each instance of the context. If these contexts need access to elements (channels etc) in the main context, you can make the dynamic contexts a child of it. That is discussed here...
Is there a way to create a "plug-in" framework for web applications that have these features:
Seemless for the developer - can use existing technologies
e.g.
Spring MVC annotations (e.g. Request Mapping)
Hibernate / JPA with annotations
JSP, JSTL, and servlet views
Seperation - class loading, session, http context
e.g. each #RequestMapping is confined to a subset of the "main" URL (e.g. one "plugin" can't hijack the URL request of another "plugin" for example the URL http://localhost/rootContext/plugin1/action1?param=value will require a mapping that is relative to the "module" / "plugin" which is "plugin1" and not the root context, so if we have full seperation of http context, I expect the annotation to be #RequestMapping("action1"...)
also Parent Last classloading so each module can have it's own jars etc..
also protection on the session object to avoid overwriting session keys accedently (and for security)
Supports plain old JSPs
I'd like to have the view tehnology be JSPs, I find them much easier than Freemarker, or Velocity
I thought of Apache Felix, OSGI, Spring-OSGI MVC etc... but still need more information...
Take a closer look at Eclipse Virgo, possibly the best choice for greenfield projects for the moment which want to include Spring and JSP.