We Keep Coding

How to dynamic generate Enum type from mysql in Java spring boot application?

In my project,we want manage all REST APIs errorcodes in a Enum type,like the following code:
package com.example.util
public enum ErrorType{
SUCCESS("0000", "success")
PARAMS_EMPTY("3001", "params cannot be empty")
}
The problem we encounter is if we put the class into util package,everytime we add a new error type in business spring boot app,we'll need to modify,publish and recompile the app and util project.That would be hard to maintance the util package.Basically,we prefer to maintance a relatively stable utility package.
So we are considering if there is a way that we can generate Enum type dynamiclly,we can comfigure the error information in mysql in advance,then we can load them into enum type in application boot procedure.
I'm not sure is this a good idea to dynamic generate enum type in Java,or if there is a better solution for this problem.

You can't add or remove values from an enum. Enums are complete static enumerations.
If you need to handle variable values you need to work with a standard class.
For example you can have something like the following:
public Error {
public static Error getByName(String name) {
....
}
public static Error getByCode(int code) {
....
}
}
and use it as follow:
Error myError404 = Error.getByCode(404);
Obviously this code gives you a lot of flexibility, but you cannot know in advance if a particular error code exists or not. And you can't use ide facilities related to enums.

Generating an enum would not be so useful I think, since part of the power of enums is that you can use them statically in your code - so then you have to update your code anyway.
How about adding a an exception handler to your util library that can be populated with error codes / description mappings from the database that can then translate errors/exceptions to response codes / error messages for your API? (just guessing you have an api here :-) )

Thanks for your reply,we finally decide to give up this idea.Dynamic generate an enum would not help,indeed it will add more complexity to our project,it's not a common use of enum.
Instead of this,we predefine our main error type likes user_error,system_error and db_error,etc.The specific error information will be processed in the business service.

Using existing enum in JHipster

When generating new Entity in JHipster, is it possible to add an existing enum?
For example java.time.DayOfWeek, currently a new enum file is generated.
Am I missing a flag or an option to generator?
Thank you!

When creating entities(2 or more), which is using the same enum(say Status with 'ACTIVE'/ 'INACTIVE'), each time we can type in the same enum and its values, and the old enum will get replaced with the new enum.
JHipster version used ("ng-jhipster": "0.2.7","generator-jhipster": "4.6.2", Spring Boot 1.5.4.RELEASE)

ui binder pattern: initializing variables using generators

I am trying to create a GWT generator that does the following:
public class MyPool {
#InitializeThisVariable
Element1 el1;
#InitializeThisVariable
Element2 el2;
private static final ChildPool childPool = GWT
.create(ChildPool.class);
interface ChildPool extends Pool<MyPool>{}
public MyPool(){
}
}
I want the generator to initialize the annotated fields. After doing some research, I have found out that the only way to do this is to use the pattern used by ui-binder as above (I do not want to use Annotations Processors).
However I get the following error when compiling:
[ERROR] Line 16: Rebind result 'ChildPool' must be a class
Help would be much appreciated.

Your generator needs to return name if the generated class. Either that or you forgot the <generate-with> in your module.
Also, your code doesn't make use of the generated Pool instance.
Note however that generators are being deprecated in GWT 2.8, and you should really use other kind of code generators (be it annotation processors or something else). You shouldn't start writing new generators nowadays.

Not the right Xstream converter selected by Cucumber

I've been using Cucumber for dozens of Java projects so far an never encountered this issue before, so I'm a bit puzzled.
I have a simple table that I want to map to a List in my step definition.
And deal repository contains
| dealPid | closingDate | expenseCode |
| 1 | 01/06/2015 | test |
I started by creating my own POJO with only required fields, following standard camel case convention (getters/setters are omitted for clarity)
public class Deal {
private String dealPid ;
private Date closingDate ;
private String expenseCode;
}
my step definition :
#Given("^deal repository contains$")
public void deal_repository_contains(
#Format("dd/MM/yyyy") List<DEAL> deals) throws Throwable {
...
}
Fields get mapped properly and I'm getting a List with one Deal item, fine. When I go in debug, up to cucumber.runtime.xstream.LocalizedXStreams
Converter converter = converterLookup.lookupConverterForType(clazz);
I see a xStream ReflectionConverted gets selected for the Datatable parsing.
This is a legacy project, and other developers then told me there was already a class existing for this. So now I want to switch to that class, that follows really strange conventions : class name is the table name on which it's mapped in DB, and most of the attributes names are actually the column names..
So now I'm using this legacy DEAL class from another package in my step definition, so I'm expecting a List to come up, but it doesn't. I get a List but even first row gets parsed. In debug, I see the converter that gets selected is a DynamicClassWithStringAssignableConverter instead of a ReflectionConverter previously, which is why the parsed result is different in the end.
Unfortunately, I'm unable to go further in debug and understand why this implementation gets selected, as Xstream is repackaged in cucumber-jvm-deps and Eclipse gets lost (or I don't know how to attach sources correctly in that case).
I tried adding temporarily the fields I need with proper names (ie same as in my initial Deal class) in DEAL class, but it doesn't work.
Initially, DEAL class was implementing Serializable : I removed it, but still the same behavior.
It actually looks like because the class name is full upper case, a different Xstream converter gets selected...
Can it really be the root cause of the issue ?
Thanks

Just hit this very surprising behaviour myself - in my case the issue turned out to be that DynamicClassWithStringAssignableConverter.canConvert returns true if the type to be converted has a constructor that takes a single, String argument.
Work around was to remove the constructor!

JAXB - #XmlJavaTypeAdapter on a WS return value

I am actually trying to build a process for refactoring a large number of existing webservices.
The idea is to use JAXB/JAXWS tools to automate this as much as possible.
Most of our issues are resolved except for one blocking problem :
JAXB by default serializes boolean types as "true"/"false". I need those values to be "0"/"1".
On the existing classes of our codebase, I'm trying to use as much annotations as possible, and of course not modifying at all what is auto generated by JAX tools.
After adding correct annotations, I run wsgen so it generates JAX-WS necessary classes for deployment.
Here is a concrete example of an annotated webservice method:
public #WebResult(name = "success")
#XmlJavaTypeAdapter(value = lu.ept.common.xmlSerializers.BooleanAdapter.class, type = boolean.class)
boolean modifyStatus(#WebParam(name = "processActionId") String processActionId, #WebParam(name = "newStatus") int newStatus)
throws BusinessMessage, SystemMessage {
When running wsgen, it picks up correctly the WebResult and WebParam attributes, but it refuses to use my XmlJavaTypeAdapter.
My question is very simple : has someone managed to use XmlJAvaTypAdapter annotation on a webservice method return value? Is it possible?
(on the documentation I read, I haven't seen anything concerning the use of that annotation on return values)
Actually the only solution I have found is to manually add the XmlJavaTypeADapter annotation to the classes generated by wsgen. This is not a viable solution, because those classes will be generated after each build...