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...
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 have a Spring Integration project that has several flows (some where between 10-15). I would like to keep my namespace clean since several flows might have similar sounding components (for ex - several flows might have a channel named fileValidatorChannel). I think I have a couple of different options to keep names from colliding with each other:
A. Preface every component name with the flow that it belongs to. For ex - flowAFileValidatorChannel, flowBFileValidatorChannel, etc
B. Create a context hierarchy where every flow is it's own context and every flow inheriting from a master context where all the common beans/sub-flows are.
What's the better approach? Is there are better way to keep my name space clean?
To be honest your problem isn't clear.
Any Spring Integration component is a bean finally. So, their ids are just to distinguish them from other bean.
Let's imaging if you don't have Spring Integration in your application. So, you would worry about some clean naming strategy for all your beans anyway?
From other side consider to use Spring Integration Flow project:
The goal is to support these, and potentially other semantics while providing better encapsulation and configuration options. Configuration is provided via properties and or referenced bean definitions. Each flow is initialized in a child application context. This allows you to configure multiple instances of the same flow differently.
While starting my Spring MVC war I need to specify the mode.
Based on mode it should start different set of controllers.
Is it possible to do the same by specifying mode/ applicable controllers
while starting it?
A similar question Spring MVC web application - enabling / disabling controller from property only talks of test but I need to have various combinations and start all controllers as default.
Spring in general has a profile mechanism that lets you register different beans in different environments
When you bootstrap it according to doc, distinguishing controllers is as simple as annotating them on a class level with e.g. #Profile("mode1") vs #Profile("mode2")
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.
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.