Our application exports its configuration as several sets of Spring beans.
I have no control over how it does this.
I want to write something that documents the dependencies between the configuration items defined in these beans. Note: these are dependencies at the application level, nothing to so with Spring dependencies (so we might have configuration items of type Actresses who have a dependency on certain items from the type Bishops, but - at the Spring bean level - this is merely that the value of a property in the Actress matches the value of a different property of the Bishop).
So I'd like to use some library or toolset that lets me load up a set of bean definition XML, iterate over them and the content of each, extract property values and so on.
From some googling, I can find ways of extending the parsing Spring does itself, but I don't want that - I want something I can run offline outside of the Spring-using app itself.
Can someone point me at some resources for doing this?
The closest thing I've heard of to this is Spring BeanDocs:
http://spring-beandoc.sourceforge.net/
Related
I have a Spring Boot app which imports an external library. I am reading the spring.xml in the dependency that I have imported. It is throwing an error because it is looking for "propDir" which I have not defined. I see an error "Invalid bean definition with name .... Could not resolve placeholder 'propDir'"
<value>file:${propDir}/env-config.properties</value>
I have seen another spring boot app import the same dependency and it starts just fine. When I debugged the start sequence and saw the value of propDir , I saw that it was not substituted and I see "file:${propDir}/env-config.properties" in the created bean.
I have searched the app , but haven't really figured out how the other app is not throwing the error. Is there a piece of config that I am missing?
You need to specify a value for propDir.
This can be done either by jvm argument like
-DpropDir=nameoffoldertouse
or via a properties file loaded via a PropertyPlaceholderConfigurer.
Other applications that rely on this bean may have a default hidden away.
It is likely that the bean relying on this value will need it to guarantee its correct behaviour, if you do not want to provide this property do not rely on the bean that uses it.
Properties to a spring boot application can be passed using different ways, very likely for the other application the property for "propDir" is I believe getting passed as one of the ways specified in this documentation: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
I would like to make all property placeholder and their resolved values of a running Spring (Boot) application available for process monitoring. In the first step this could be just by writing them to the logs or by creating a 'resolved.properties' file similar to the application.pid file.
All properties where property placeholder are used (implicit/explicit) should be considered.
Motivation: It is usually hard during operation to know the values of resolved properties. System properties or command line arguments are "visible" but e.g. hidden default values in the code (like #Value("${timeout:30000}")) are hard to find out. I would like to be able to answer the question "How does the configuration of the running application looks like?" in a generic way that I can use in all of my spring applications.
I know about the Spring Boot Actuator /configprops endpoint, but this only includes #ConfigurationProperties. I would like to get a list of all properties where placeholder are used.
The requirement does not seem to be new (see here or here) but I wonder if there is an appropriate (bootiful) way nowadays.
There is (currently) no way to obtain all the properties in the Environment abstraction. This is intentional as can be read here. This is also why it isn't possible to obtain all the values used for resolution.
The values and resolutions are logged at runtime telling which key was resolved from where at runtime. But that logging is quite verbose and logged each time a StringValueResolver is used.
You might get a partial result by providing your own customized PropertySourcesPlaceholderConfigurer which maintains a collection of resolved key/value pairs. But not every resolution uses the PropertySourcesPlaceholderConfigurer some directly use a StringValueResolver implementation bypassing the PropertySourcesPlaceholderConfigurer.
It doesn't cover all your needs (ie: properties from all files, default values, application arguments, etc.).
I'll still keep the answer for other readers/future reference.
Spring Boot's Actuator /env endpoint
You may use the /env endpoint. It lists a bunch of stuff but it also includes the content of application.properties (near the end):
applicationConfig: [classpath:/application.properties]={myproperty=blah, server.port=8080}
I'm reading through Spring Integration documentation and I still can't get into one thing: does Spring resolve all dependencies and make that automagic IoC dependency injection at compile time or at runtime?
I believed that it is runtime job to wire available components together in a data route from gateway to some data endpoint (e.g. DB). But since most of examples are made using DSL syntax in java, it seems that it's a compile time job.
So, glueing together beans in a data highway can be made only at compile time?
Summing up my comments here :
1) Spring IOC container manages beans from its creation till destruction. What this means is the beans are ready in sort of a bucket, which is a ready to use application. Thus, it is necessary to create the contents of the bucket at compile time, rather then runtime. This does not include hot-swapping of beans.. I hope this is what you were looking for.
2) You can create as many routes as you want, those all beans will be put in the container.... And as far as I understand, you cannot just change your source code and synchronize it with already running one, you have to atleast do a graceful restart. There is a bottom line to this, Spring must see if all beans are properly autowired, no circular dependencies, and there is no expectation of source code during run time. Sure you can get your beans via RMI, but that doesn't count as you have declared it already. So yes, compile time it is
The java DSL syntax is simply a different way of defining a flow definition (a series a bean definitions). The beans are still created and wired together during application initialization (runtime).
I'm working in a webapp and this is the first time that I'm using Java based configuration. I have a bunch of class to configure all:
ApplicationContext
PersistenceContext
SecurityContext
WebAppInitializer
WebMvcContext
Now I'm defining Spring Data repositories and the service layer so I need to inject the repositories there. Normally I would use Autowired but I've read that it is preferable to define the injections manually so the question is, where?
Maybe neither of the previous configuration classes is suitable for such task but, do I have to create a single class to define all the injections or is better to have on for each function? What happens if the project grows too much?
I think that the main question would be what is best way to organize dependencies in a Spring project. What do you do?
I add here an image of the structure of the project as a petition. I'm trying to decouple layers and now I need to inject UserRepository to UserService.
No, I would not define a single class to do all the injections. All your classes are coupled that way.
I don't understand what "define the injections manually" means. You have to specify them in either XML or annotations. There's no other way that I know of.
You don't say if you're using XML or annotation configuration. I find myself using the latter more of the time, with only enough XML configuration to tell the Spring app context to scan for annotations.
The Spring idiom would have you specify your configuration in layers if you're using XML. It's a moot point for annotations, because they go into your source code.
Your application will read the Spring context on start up, instantiate all the beans, and wire together the necessary dependencies. You're good to go from then on.
I disagree with the link you provided. Avoid autowiring? No.
The article said that he recommends using XML configuration for large projects. This is a very small project at this point. It seems to me that auto wiring with annotations would be fine even by the article's author's words.
I am developing a SWT component in which there is a child component through which user can view the Spring reference and can change the Spring bean definition, property etc..
I am facing 2 issues:
If the defintion of bean is defined in some other Spring XML rather than the selected Spring file, then how to proceed.
How to fetch source code of class (for preview) from defined beanClass e.g. com.xyz.abc.def.Foo.
For getting the info from the spring xmls, you have to do some parsing, there is no beating around that. However you could use O/X Mappers to simplify this process http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/oxm.html
As codejammer said, you will have to parse all xml files and possibly also included files through different mechanisms. The safest would be to use Spring's own classes to deal with it. More specifically, see XmlBeanDefinitionReader[1] for reading and using a, possible custom, implementation of BeanDefinitionRegistry[2] for holding a map of your valid beans.
The second problem of loading the source for a class, that is as easy as changing the class' packet name to a fully qualified path: com.xyz.abc.def.Foo -> com/xyz/abc/def/Foo.java
http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/beans/factory/xml/XmlBeanDefinitionReader.html
http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/beans/factory/support/BeanDefinitionRegistry.html