try to fix one issue in our old spring application. Unfortunately source was lost and I have difficulty to decompile jpa entity. The class is decompiled sucessfuly but there is only basic anotation as #Entity, #Table. There is completety missing links and column names between entity classes (#OnToMany, #Column, etc). I have tried decompiler cfr, d4j, procyon but without sucess.
Does anybody know if it is possible and what kind of decompiler is able to do that?
One I use is http://jd.benow.ca/
Maybe all metadata isn't specified in annotations? if in XML then a decompiler clearly won't give that.
If decompilation gives you just partial results it could be that some annotations are not targeting runtime.
This should however not be the case for any hibernate annotations.
One possibility could be to create a new spring test app, include your jar and launch a component scan on #entity, #mappedsuperclass and #embeddable. You would have to process the classes after yourself using reflection but at least you should be able to get everything out of it.
Should be some work though. Make an opensource project out of it after ;)
Related
Over the course of writing Spring Boot apps, our team adds in a lot of #Value annotations to help make things configurable. At some point we start to lose track of exactly what we added and what can be configured. We get a lot of questions from the QA and DevOps teams about what exactly can be configured and what can't.
Currently we just do a grep through the code base and apply some crude regular expressions to try and parse out the meaningful pieces. But this doesn't catch 100% of cases and inevitably we end up digging through the code to find out what fields can be configured.
I know we could use JavaDoc to somewhat achieve our goal, but the documentation would be buried with other JavaDoc (methods, fields, classes, etc) and it's still reliant on developers to remember to add the JavaDoc to each field.
Has anyone found a more automated way to document their #Value fields? I'm thinking something like Swagger, but specifically for Spring and the various ways it can externalize configuration.
Javadoc is indeed a way to document for developers, not the QA or the operators.
Your question is really interesting but answering to that canonically is hard because #Value are implementation details of components. Swagger that you quote documents REST contracts, that is an important difference.
Here some ideas :
Writing a BDD test for them that could be used too as documentation makes really no sense functionally but technically it makes.
Indeed, you could write a BDD integration test (with Cucumber or any other library) where you document and test the presence of each expected property.
Not a perfect solution, but you could at least retrieve exposed properties and a little more with these Spring Boot actuators :
configprops : Displays a collated list of all #ConfigurationProperties.
env : Exposes properties from Spring’s ConfigurableEnvironment.
Whenever you can, favor #ConfigurationProperties injection to group properties that work together rather than #Value. Isolating them in #ConfigurationProperties classes and adding javadoc for them is not bad at all to document their presence and usage.
as suggested by caco3 you can also generate your own metadata by using the Annotation Processor :
You can easily generate your own configuration metadata file from
items annotated with #ConfigurationProperties...
The processor picks up both classes and methods that are annotated
with #ConfigurationProperties. The Javadoc for field values within
configuration classes is used to populate the description attribute.
It joins with the previous point : favoring #ConfigurationProperties whenever it is possible.
I have been reading about Spring Boot custom repository. I have dozens of blogs explaining how to implement those but none of them explained scenario when we actually need it?
I mean one example where we cannot live without custom repo. I mean if there is case of complex query, we can anyhow achieve it using #Query.
Please explain.
Lets say I want strongly typed query instead of #Query. I would create a custom repo, autowire EntityManager and use QueryDSL with it so I can use strongly typed references.
You can use it to extend the repository with other libraries that aren't part of Spring.
I find them useful when working with a program generator like jHipster. They keep your code separate from the generated code.
The xxxRepositoryCustom.java xxxRepositoryImpl will not be overwritten when the entities are re-generated by a dumb programmer (me.) The queries themselves have some complex logic that can not be expressed in a simple #Query
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.
I have years of Java experience on Eclipse and now would like to get my feet wet with Spring. After read some tutorials I have such a question: is it easy (or even possible) to find classes/methods references in any IDE that supports Spring? By using Spring there should be no direct references among some classes, instead they are configured in xml files.
Even further: how to manage those xml files if my project gets large, say with thousands or hundreds classes? I mean perhaps it is easy to get lost among those complicated configuration files.
Spring is a dependency injection engine. This means that it injects instances of A into beans which are dependent on A. So if bean B has a dependency on A, it will have a field of type A, and Spring will initialize this field for you.
Finding the references is thus trivial: select one of A's methods, choose "Call hierarchy", and if B calls this method of A, Eclipse will find it. It's not different from any other Java project not using Spring.
Regarding the size of the XML files, Spring also uses annotations to inject beans, so the XML file can be reduced to a minimum.
With STS or the Spring-IDE plugin, it is possible to click on the class definition in the spring xml file and you will be direcly "forwarded" to the class.
And for example you build a view where the bean instances are displayed in an uml like class diagram. To get an overview how which bean is connected to other once.
But really you will not need that.
If you implement against an interface then it should not matter which concrete class is implementing the interface.
And if you implement against an class, then you know that class already.
I'm running eclipselink in an OSGi container and my entity classes are in their own bundle.
I have repeatedly run into the problem that Eclipselink fails to autodetect the entity classes, resulting in "Xyz is not a known entity type" messages. This is painful to debug and my somewhat helpless approach is to more or less randomly tweak configuration files until it works.
I wish I knew a more systematic approach, but I don't seem to know enough about possible reasons for the problem. What could they be? Is there an overview of what happens in autodetection and what is required for it to work?
So if you ran into the problem yourself and were able to determine one specific reason, post it here, or vote it up when you already see it. That way we could produce a list of typical issues sorted by frequency. I'll add the ones I actually solved.
Facts I know:
eclipselink uses the OSGi extender pattern to listen for bundles registering and then sets them up
it supposedly uses the class loader for the bundle that defines the persistence unit, if you're using a persistence.xml for configuration, this is the bundle where that file should be located.
The eclipselink jpa is not able to persist objects of classes that extend entity classes. Those extended classes should be entity classes by itself.
The bundle with the entity classes doesn't have the correct JPA-PersistenceUnits header in its manifest. This header is how eclipselink finds out that there is a persistence unit to be processed.
If listing your classes explictly makes it work, the wrong / missing header was not your problem.
The entity class is not listed explicitly in the configuration of the persistence unit and the persistence.xml (or whatever config mechanism you use) doesn't set the exclude-unlisted-classes parameter to false (depending on whether you run Java SE or EE, it may be true by default).
If it helps to list your classes explicitly, this may be your problem.