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
Related
I love the Spring properties loading mechanism. The fact that you can define several profiles and override or extend properties with other profiles, that you can use different file types (.properties, XML, JSON, ...) to store your properties, that you can use the value of other properties to resolve its own value, aso.
But to use the properties, you have to somehow initialize the Spring context (#SpringBootApplication or #SpringBootTest). And I would like to use this property loading mechanism in some libraries, where I cannot guarantee that the context is loaded (and I do not want to load it).
So, my question:
Can I somehow create a class that uses the Spring libraries to load the properties (on demand) in the same way Spring loads its properties?
Other classes will then use this class to access the properties. No need to load with annotations.
I was searching for this for some time, but I haven't found a solution, yet.
Would be great if so. knows a solution for that.
Regards, stay healthy and merry X-Mas!
The property lookup mechanism is defined by interface PropertyResolver, extended by interface Environment to support profiles, further extended by interface ConfigurableEnvironment to support PropertySources, i.e. the concept of searching through a set of property sources to find a property.
It is implemented e.g. by class StandardEnvironment, which defines property source for:
system properties
system environment variables
All the above are part of package org.springframework.core.env, i.e. part of the spring-core-XXX.jar file.
Support for application.properties files is added by class ConfigFileApplicationListener in package org.springframework.boot.context.config.
The class needs an instance of SpringApplication in package org.springframework.boot.
They are part of the spring-boot-XXX.jar file.
So, getting basic Spring property support is easy, just create a StandardEnvironment object.
Getting application.properties files loaded is deeply embedded in the Spring Boot code, and would be really difficult to do without initializing the Spring context.
I have an application that consists of a grid of hazelcast nodes which uses extensive runtime bytecode generation (asm). Specifically I am dynamically building predicate<> Java functions from user entered filter expressions. I would like to store the predicates in a map so that they are available across the cluster without having to be recompiled. Predicates are not the only instance of this. I also have ORM style mapping classes that are generated at runtime which need to be shared across the cluster. These classes are loaded by a custom classloader called DynamiClassLoader.
At first I was unable to store my custom generated classes in Hazelcast IMaps, getting a ClassNotFoundexception. However, I found if tell Hazelcast to use my custom DynamicClassLoader using Config.setClassLoader() then it is able to find my dynamic classes and use them in the local member so I have no issues serializing and deserializing instances of my custom classes in IMaps in the same member.
However, I am still unable to deserialize instances of my predicates which were inserted into the map by a different member. I have enabled UserCodeDeployment and stepped through the code in my debugger to confirm that if it cannot find the class locally then it is hitting UserCodeDeploymentClassLoader.java and on the classNotFoundException it is proceeding to check other members for the classes but it is unable to find them. I haven't been able to discover how exactly this works. it seems to look in an internal map for which member any given class can be found on and it does not find my classes in there. I believe it dispatches an operation to other members then to look for the class, but in this case it looks like my custom classloader isn't used so it's not able to find my custom classes.
How can I make dynamically generated classes work with UserCodeDeployment on Hazelcast? Is there a way I can 'register' my dynamic classes with the member's code service or something like that?
Thankyou,
Troy.
I've finally figured this out after extensive debugging. It turns out that the operation in Hazelcast on the target member to find a class calls loadBytecodeFromParent() in ClassDataProvider.java. This looks for a .class file using getResourceAsStream on the classloader:
String resource = className.replace('.', '/').concat(".class");
...
is = parent.getResourceAsStream(resource);
Which basically looks for the class file on the filesystem. Since my dynamic classes are entirely in memory there is no .class file resource for it to find.
I resolved this, by putting a hashmap in my DynamicClassLoader to keep the generated bytecode in and overriding getResourceAsStream to return that bytecode when it's available before looking further. Now it works!
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.
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/
There is an ejb-jar xml file in our project which defines essentially the same ejb configuration over and over again for a number of different brands. They all share the same underlying code, the same external references etc., so could in fact all be mapped to the same single definition.
The argument is that in future if there is some distinction required between the brands, then the mechanism is in place to manage each pool and configuration separately. This I can accept.
I would however still like to condense this rapidly bloating file. A suggestion floated around was to use XSLT to transform a bespoke xml configuration, but this introduces another type of complexity that I'd like to avoid.
My question then is, does anyone know if the specification supports any means of inheriting some kind of parent or common configuration into the definition of an ejb?
There is no inheritance for EJB component definitions. Some suggestions:
If you're willing to use annotations, you could specify most of your component configuration in the bean class, and then reuse the same <ejb-class/> for multiple <session/>.
If you're using a JavaEE 6 server and you're just trying to cut down on refs, you could consider defining your refs in java:module/env, and then they will be visible to all beans in the module.