Is it possible to insert a value stored in a configuration file (eg: application.properties) inside java annotation as follows :
#MyAnnotation(name="${application.prop1}")
and in application.properties I have:
application.prop1=foo
So that at runtime I have :
#MyAnnotation(name="foo")
Yeah, I don't think this is possible. Spring has no idea about your annotation and doesn't know what to do with it. Even if you try to use #Value(..) on top of your String name() default "" (inside of your annotation), Spring still won't make this happen as the annotation is not a bean. Trying to make your annotation a bean won't work either as far as I can tell. It sound like you are going to have to come up with some type of processor for this.
Perhaps looking into the following topics might help give you some ideas on how to put this together:
Auto Configuration: https://www.baeldung.com/spring-boot-custom-auto-configuration
SPeL: https://www.baeldung.com/spring-expression-language
Java Reflection: http://tutorials.jenkov.com/java-reflection/index.html
And of course, there's always the possibility that you might want to step back and consider why you want to do this? What are you trying to achieve that perhaps can be done a more "out of the box" way.
Yes, yse #Value annotation
#Value("property1")
I have recently upgraded to Genson 1.3 and I am not 100% sure if this issue is new or not as previously I patched the 0.98 version to make it work.
Context
We are using our own implementation of the BeanMutatorAccessorResolver. This is so that we can dynamically decide whether a property should be serialized or not. Basically we have integrated Genson into our generic jersey REST API interface. Genson does all the serializing and deserializing. When doing a GET requests it is possible for a user to pass fields in the URL in order to filter those he specifically needs (especially for large objects this is necessary where you only need 3 fields or so for displaying a table overview). For example: ?fields=field1, field2, field3. We then know in our implementation of BeanMutatorAccessorResolver exactly which fields to serialize and which ones to ignore. This is mainly intended for speeding up requests and parsing as we are then working with less data.
Problem
Unfortunately it seems that once Genson has read in all the fields via reflection or whatever, it caches that. This would be no problem if we were always requesting the same fields. Unfortunately on some occasions we need more fields then before, but because Genson does not visit our BeanMutatorAccessorResolver a second time it only returns the few fields that it has already cached.
Is there anyway around this? Perhaps there is a better solution than turning cahing off completely - because that would most probably hurt performance, right?
Update
Is seems that I have found the location where this is happening. Basically Genson returns a cached converter in Genson.provideConverter(Type forType) (line: 154).
Converter<T> converter = (Converter<T>) converterCache.get(forType);
At the top of the method I have noticed that it looks for a __GENSON$DO_NOT_CACHE_CONVERTER.
if (Boolean.TRUE.equals(ThreadLocalHolder.get("__GENSON$DO_NOT_CACHE_CONVERTER", Boolean.class))) {
Should I perhaps set this value or is there a better solution?
The problem has been solved thanks to Eugen. The solution can be found here: https://groups.google.com/forum/#!topic/genson/Z1oFHJfA-5w.
Basically you need to extend 3 classes to get this working:
GensonBundle, which you can register with the GensonBuilder.
BaseBeanDescriptorProvider, which gets created in GensonBundle.
BeanDescriptor, which gets created in BaseBeanDescriptorProvider and
which contains the serialize method to adapt to your needs.
I was reading the Jersey docs about bean validation. The ParameterNameProvider example shows how to define parameter names for a method. However, the implementation looks like this will have to be done for each and every method which obviously doesn't scale. The example is basically useless as is.
Is there a smarter way to do this? Couldn't Jersey infer the name from #QueryParam or #PathParam annotations?
Take a look at the answer in my question here. It should do exactly what you want.
Can I change the property path in a ConstraintValidator for Method arguments?
If you copy my code and run it through a debugger you will see that it is only evaluated once for each method for which it is used. Then during normal running of your app the names will not need to be resolved again.
I was wondering if I can easily annotate Acceleo templates and then get these annotations when working with TraceabilityModel.
Acceleo is now using an annotation to determine entry points for generation:
[comment #main]
So I am asking, if I can use this mechanism to annotate my templates for other purposes, for example:
[comment #org.project.SimpleStatement]
[template public generateSimpleStatement(...)]
...
[/template]
Then, I could be able to get the annotation programmatically when working with traceability model (probably using the org.eclipse.acceleo.traceability.ModuleElement interface).
Acceleo's traceability does not support either annotations or comments : we only record traceability information for the actually generated text bits, not for any of the "extra" information (comments of the module, main annotation, metamodels ...).
That being answered, and though not possible through the means of an annotation, maybe your use case would be worth an enhancement request? Can you describe what you were expecting to achieve through this? (preferrably through the Eclipse M2T forum since stack overflow does not seem to be appropriate for such discussions ;)).
(Note : I am an active developper on Acceleo)
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
How and where are Annotations used in Java?
Java beans, annotations: What do they do? How do they help me?
Over and over, I read about Java 5's annotations being an 'advanced feature' of the language. Until recently, I haven't much used annotations (other than the usual #Override, &c), but work on a number of webservice-related projects has forced my hand. Since I learned Java pre-5, I never really took the time to sit down and grok the annotation system.
My question- do you guys actually use annotations? How helpful are they to you, day-to-day? How many StackOverflow-ers have had to write a custom annotation?
Perhaps the most useful and used case of Java Annotations is to use POJO + Annotation instead of xml configuration files
I use it a lot since (as you already stated) if you use a web framework (like spring or seam) they usually have plenty of annotations to help you.
I have recently wrote some annotations to build a custom statemachine, validations purpose and annotations of annotations (using the metadata aspect of it). And IMO they help a lot making the code cleaner, easier to understand and manage.
Current project (200KLOC), annotations I use all the time are:
#NotNull / #Nullabe
#Override
#Test
#Ignore
#ThreadSafe
#Immutable
But I haven't written yet my own annotation... Yet!
I have used annotations for:
Hibernate, so I don't need to keep those huge XML files;
XML Serialization, so I describe how the object should be rendered in the object itself;
Warning removal for warnings that I don't want to disable (and for which the particular case cannot be properly solved).
I have created annotations for:
Describe the state required in order for my method to be executed (for example, that a user must be logged in);
Mark my method as executable from a specific platform with additional properties for that platform;
And probably some other similar operations.
The annotations that I have created are read with Reflection when I need to get more information about the object I am working with. It works and it works great.
Annotations are just for frameworks and they do work great in hibernate/jpa. until you write a framework that needs some extra information from passed to it objects you wont write your own annotations.
however there is new and cool junit feature that let you write your own annotations in tests - http://blog.mycila.com/2009/11/writing-your-own-junit-extensions-using.html
I use annotations daily and they are wonderful. I use them with jsf and jpa and find them much easier to manage and work with than the alternative XML configurations.
I use annotations for describing in my state synchronisation system what classes are specialisations of the annotated classes, and the environment in which they should be used (when an object is created, it will work out for its entity lists which are the best entity classes to create for the nodes on the network; i.e., a Player entity for a server node is instead a ServerPlayer entity). Additionally, the attributes inside the classes are described and how they should be synchronised across machines.
We just used annotations to create a simple way to validate our POJO's:
#NotEmpty
#Pattern(regex = "I")
private String value;
Then we run this through the Hibernate validator which will do all our validation for us:
import org.hibernate.validator.ClassValidator;
import org.hibernate.validator.InvalidValue;
public void validate(T validateMe) {
ClassValidator<T> validator = new ClassValidator<T>((Class<T>) validateMe.getClass());
InvalidValue[] errors = validator.getInvalidValues(validateMe);
}
Works great. Nice clean code.
We use custom annotations as a part of our integration testing system:
#Artifact: Associates an integration test with an issue ID. Trace matrices are then automatically generated for our testing and regulatory departments.
#Exclude: Ignores an integration test based on the browser platform / version. Keeps the IE 6 bugs from clogging up our nightly test runs :)
#SeleniumSession: Defines test specific selenium settings for each integration test.
They are a very powerful tool, but you gotta use them carefully. Just have a look at those early .NET Enterprise class files to see what a nightmare mandatory annotations can be :)
We have a report builder as part of our webapp. A user can add a large number of widgets that are all small variations on the same set of themes (graphs, tables, etc).
The UI builds itself based on custom annotations in the widget classes. (e.g. an annotation might contain default value and valid values that would render as a dropdown. Or a flag indicating if the field is mandatory).
It has turned out be be a good way to allow devs to crank out widgets without having to touch the UI.