I have a property file like myProperties.properties. I want to read one property like MAX_YEARS using spring annotation #value as like below in UIMA JCasAnnotator_ImplBase extending class.
private #Value("${REQUIRED_COLUMNS}") String requiredColumns;
Or any alternatives for reading properties from property file in UIMA framework.
Thanks in advance.
Narasimha.
UIMA does not support value injection via Java annotations (from Spring or any other DI frameworks) at this time. It does support External Configuration Parameter Overrides, though.
uimaFIT offers annotations like #ConfigurationParameter to inject UIMA parameters into fields. These parameter values can come from descriptors automatically generated by uimaFIT using reflection, or they can come from pre-built XML descriptors.
When using pre-built XML descriptors, it should be possible to employ the External Configuration Parameter Overrides mechanism in conjunction with uimaFIT - but I am not sure if this has already been tried by anybody.
It may even be possible to employ the External Configuration Parameter Overrides mechanism with the descriptors internally generated by uimaFIT.
Disclosure: I am a developer on the UIMA project, focussing on uimaFIT.
Related
I have been looking for an explanation of how Spring Framework will look for #AutoWired properties. I have noticed that when using the hikariCP library that setting either of the properties below will result in a correct max pool size.
spring.datasource.hikari.maximumPoolSize=3
or
spring.datasource.hikari.maximum-pool-size=3
Does Spring use both camel case and hyphen separated to lookup autowired properties? Where might I find an explanation in the spring docs?
That isn't a feature of the core Spring Framework but rather a feature of Spring Boot.
Spring Boot has a feature called relaxed binding which is used for properties mapped to a class annotated/used with #ConfigurationProperties. Each property that is being bound can be used with camel-case, dashes or even uppercase with dashes (generally used for environment variables!).
So all of these will work in the same way (the latter is often used to pass it as an environment or system variable).
spring.datasource.hikari.maximumPoolSize=3
spring.datasource.hikari.maximum-pool-size=3
SPRING_DATASOURCE_HIKARI_MAXIMUMPOOLSIZE=3
There are valid and invalid properties, but Spring's #ConfigurationProperties, which used mostly for loading configurations, works with both forms of properties.
The issue can be if any framework, library, etc. use property separately, without #ConfigurationProperties. In this case, you will have runtime exception (or null value).
Most default, base, popular properties are here: https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html
Currently we are using GemFire for caching. We are in our initial phase of integrating it.
While we are working on integrating GemFire using the Spring Data GemFire libraries, and using GemFire's PdxSerializer, too, I am wondering if there is a way to convert fields to/from PDXReader/PDXWriter using basic annotations and Java Reflection.
We are using Sprint Boot's 2.0.3.RELEASE JARs.
Note: I have looked at the below link:
https://gemfire.docs.pivotal.io/95/geode/developing/data_serialization/auto_serialization.html
I am more curious how to use a non-XML way of doing this.
Have a look at the following:
SDG's o.s.d.g.mapping.MappingPdxSerializer as described in the documentation.
Then read how to configure it.
If you are using Spring Boot for Pivotal GemFire, then PDX is auto-configured automatically, by default, for you and you do not need to explicitly declare SDG's #EnablePdx annotation.
NOTE: SDG's MappingPdxSerializer, when configured and registered with Pivotal GemFire, automatically de/serializes your application domain object types without any special config, like you have to do when using GemFire's own ReflectionBasedAutoSerializer and clumsy REGEX to identify your types properly, blah! SDG's MappingPdxSerializer is much more robust, using first-class filters to express exclusions and even inclusions (which can override the default exclusions, that is any class types in java.*, com.gemstone.gemfire.*, org.apache.geode.* or org.springframework.*, by default).
Anyway...
Take 2 pills and call me in the morning - the "doc", ;-)
I am trying to use configuration file to persist OSGi configuration in Karaf 3.0.0 and having some issue when using property with array of values. My configuration file is placed in /etc folder and looks something like this:
property = ["value1","value2"]
The problem is that array does not get interpreted properly, so in Web Console I see one string value instead of array of values. I figure out that if I use .config as extension for the configuration file, the array gets interpreted properly, but I experience another issue then, like for example that my config file gets overwritten. Is there any way to use .cfg extension and somehow indicate that the property is array?
You might want to take a look at the OSGi Configurer RFP and the OSGi Configurer RFC. OSGi enRoute, which inspired this upcoming spec, has a bundle and some documentation for it.
The Configurer maps JSON to (the spec will be likely YAML) to configuration admin. That said, we generally then use interfaces that define the properties so we can convert the actual configuration type to the type that the code needs automatically. This model is used in DS for configuration and (annotation interfaces in that case). OSGi enRoute has special support for this model with the DTOs service. (Which is also being specified.)
I use Apache commons config very often, and its a great library .
I wander what's springs solution to handling property files.
I have seen a few DataSource JDBC config examples, and I want to know more.
hope it has set of great features the commons offers, such as variable substitution etc..
For a quick introduction, check Spring 3.1 M1: Unified Property Management. From the summary:
Summary
Spring's Environment abstraction provides a single location to configure both profiles and properties. Profiles, as described in earlier posts, determine which bean definitions should be registered for a given deployment context; the property support described in this post provides a consistent abstraction over any source of properties, resulting in more flexible property access and placeholder resolution throughout your application configuration.
I started learning spring today and i have a question regarding what happens to the annotations when java files with annotations is compiled ?.
The reason i am asking this is because of the fundamental difference i see when we choose to use the xml approach vs the annotations approach , and what i think is the philosophy of spring. The way i understand is spring says that all your java classes can be simple pojo's and all the spring related config should be kept independent (Like xml file.)
In case of developing spring application using xml *.java files have no idea about spring container and are compiled in to .class without any spring related dependencies.
But now when we annotate the .java file and the file is compiled the compiled file now has all spring related dependencies hard baked in to it and no longer are your classes simple pojo's.
Is this correct ? I am not sure if i am missing some thing here.
Annotations can be considered as metadata of a class or its element (method, field, local variable...). When you put annotation, you don't implement any behaviour. You just give additional info on an element.
That way, Spring, which is in charge of instanciating its bean can collect the info with reflection (see also this site) and process it.
To conclude, your Spring beans still remain POJO and there is no difference with the XML way (...from that point of view) since Spring gets from annotations the information it would have got from XML .
I think you are right and your question is justifiable, that's the way how I think about it too.
Not only compiled code but also dependency on spring jars bother me. Once you use this annotations your resulting jar depends on spring library.
It's reasonable to store beans in model according to DDD but spring is some kind of infrastructure layer so I didn't like the dependency.
Even if you would use XML, it's useful for few placed to use attributes. E.g. #Required attribute which is useful to verify that linked bean was injected. So, I've decide to use constructor dependency injection to omit this attribute, see my article. I completely leave out the dependency on spring in the code.
You can probably find such mind hook for many annotation you want/force to use.
You can use annotations only for your configuration classes, without marking them actual bean classes. In such scenario if you not use spring you just not load configuration classes.