I have a Java class which is auto-generated from a xml schema file using JIBX. I'd like to have a default value for a class attribute. I have set the default attribute value in the xsd, but I do not see any changes in Java class source code when I regenerate it. I'd expect to see a default constructor which sets default values or attribute initialization in its definition, but I don't see either. Maybe JIBX will embed this code in class bytecode optimization? The issue is that I also use the class in my code and, when I try to manually create it, the default value is not set.
Am I doing something wrong or JIBX was not meant to work like this?
It seems there are no options you can pass to org.jibx.schema.codegen.CodeGen to fix that problem
File binding.xml supposed to be maintained manually so as a workaround you can add "default" attribute to you value "tag" like in the following question:
How to set a default value when a field is null in jibx binding?
Related
I tried enabling the -parameters flag in a project in order to use the JDBI ConstructorMapper without having to annotate each parameter.
What I then discovered was that the Jackson serialization changed behavior. I have been able to identify two things that have changed, but I have been unable to find any documentation on it.
When using the JsonCreator with mode default it now defaults to mode PROPERTIES when before it defaulted to mode DELEGATING. I now have to set this explicitly.
When using JsonProperty on a constructor parameter, that name is also kept when serializing the object. It used to serialize to the getter name, unless anything else was specified.
Are these all the changes to Jackson behavior? Also, are there any global settings I can change, so that I don't have to add lots of new annotations to my codebase?
I have tried looking for documentation, but it is hard to find the correct search terms.
I have a java app that uses guice to do configuration.. I dont think this is what it is intended for but its what has been done and I only need to make a small change so I would prefer not to remove guice.
Basically, java properties are bound to variables, I want to bind some to an environmental variables or to a java property.
This is what I currently have
bindConstant().annotatedWith(Names.named("value")).to(properties.getProperty("java.property.value"));
this is what I would like to do
bindConstant().annotatedWith(Names.named("value")).to(System.getenv("JAVA_PROPERTY_VALUE"));
Is there a way to combine the two? I cannot do both. Or, is this just a default and I basically have what I need already? ie if I do bindConstant to System.getenv that value will be used unless its overwritten in the properties file (in my case the string constant is not the full property name so I am unsure how it works now).
I really do not know much about how guice works, I believe an injector is created where this code is and later used to do things like...
#Inject(optional = true)
#Named("value)
private String value;
I basically want that value to default to the one in the properties file, but be overridden by the env property value if its present.
I have tried simply using the env var value if it exists otherwise the property value, ie
bindConstant().annotatedWith(Names.named("value")).to(System.getenv(envVarName) != null && !System.getenv(envVarName).trim().isEmpty() ? System.getenv(envVarName) : properties.getProperty(propertyName));
Which works as expected when the environmental variable is defined and the property is not defined, but when both are defined the property is always used.
Which just leads me to the fact that I know very little about guice and how it works, I have in code a very explicit binding between the property name and this method, but, it just seems to be a default value, something after that is overwriting my value with the one from the property file.
This is super basic, but it's how we do things:
get Properties (sys.properties)
some.random.prop=localhost
iterate through System.getEnv() overriding all the Properties
// Convert SOME_RANDOM_PROP to some.random.prop
properties.put(parseKey(entry.getKey()), entry.getValue());
Now your properties should be defaulted to app.properties and overwritten with matching env.properties, then just bind all he properties.
Names.bindProperties(binder(), properties);
The caveat here is that now System.getEnv() pointless, but since you're using Guice for all your injections this shouldn't really be an issue.
In spring, we can use #value annotation to refer a property value that is defined in the property file. In this approach, the way it would be something like
To have a separate property file and define the property name and value
To list this property class path in a spring config file
Finally referring the value in a class with #value annotations as
#value("{key_name}") String abc;
Other hand , we can try simply define that property value as a constant in the class something like the below and use it in the class.
public static final String key_name = "1q2w3e";
Since we have this simple approach, why we are using #value annotation approach as defined above.
Please help me to understand in detailed about it.
Using configuration values from external sources (e.g. property files) has many advantages. Some of them:
You can change the configuration without recompiling your code.
You can have multiple instances of the same binary-code running with different configuration values.
Configuration values can not only come from property-files that are bundled with your application, but from different sources like system-properties, environment-values, a database or any other custom source.
As a general rule only use constant values for things that will never change like the value of PI.
There's a big disadvantage in using the second method. Think of a scenario where you changed the language. If you were relying on the first approach you'd have to go through each class and change the value assigned to key_name. Now, if you were using the second method you'd only have to change the value assigned to key_name in one place, and that's in the properties file which is much simpler and make things more manageable.
I have an OWL file (OWL2) that I need to parse and ultimately write the data into some file. The file contains AnnotationProperties, DataProperties, ObjectProperties and Classes.
My first aim is to try to list out the property information as much as possible. i.e. for AnnotationProperties to see if I can print out the name of the property and the "value".
Similarly, to be able to display the class details i.e. for each class, the name of the class, the properties i.e. data or object properties of the class. I'm not sure how to do this and any reading I've done so far is confusing because it seems to talk about instances, which I don't believe are present in the file. Also, the OWLAPI javadoc and documentation and such are not very helpful with the kind of methods I might have to be calling.
E.g. if I had the following AnnotationProperty:
<owl:AnnotationProperty rdf:about="&xxx;SOME_ID">
<ABC rdf:datatype="xsd;string">1235412</ABC>
</owl:AnnotationProperty>
ontology.getAnnotationPropertiesInSignature() would get me a set of AnnotationProperties and I can iterate and say property.getIRI().getFragment() to see the SOME_ID, but now how would I obtain and display the inner contents i.e. the ABC-1235412 ? Similarly, any help on how to obtain the information of a class i.e. display or show its properties and restrictions is appreciated.
The fragment you're showing does not create an annotation assertion axiom with property SOME_ID, it is instead an annotation on the property SOME_ID itself. The triple looks like this:
SOME_ID ABC "1235412"^^xsd:int
From your description of what you're trying to do, you /need/ instances - values for any property (annotation, object or data property) are expressed through assertions, i.e., axioms which refer to an individual (or instance - the two names refer to the same concept).
E.g.,
Ignazio hasAge "38"^^xsd:int
would be a data or annotation property assertion on the individual Ignazio with value 38.
To access these assertions, you can use
OWLIndividual ignazio = ...
ontology.getAnnotationAssertionAxioms(ignazio);
To access annotations like the one you show, i.e., on the annotatio property itself:
OWLAnnotationProperty some_id = ...
ontology.getAnnotationAssertionAxioms(some_id.getIRI());
Just another Java problem (I'm a noob, I know): is it possible to use dynamic property binding in a Custom Control with a dynamic property getter in a Java bean?
I'll explain. I use this feature extensively in my Custom Controls:
<xp:inputTextarea id="DF_TiersM">
<xp:this.value><![CDATA[#{compositeData.dataSource[compositeData.fieldName]}]]></xp:this.value>
This is used in a control where both datasource and the name of the field are passed as parameters. This works, so far so good.
Now, in some cases, the datasource is a managed bean. When the above lines are interpreted, apparently code is generated to get or set the value of ... something. But what exactly?
I get this error: Error getting property 'SomeField' from bean of type com.sjef.AnyRecord which I guess is correct for there is no public getSomeField() in my bean. All properties are defined dynamically in the bean.
So how can I make XPages read the properties? Is there a universal getter (and setter) that allows me to use the name of a property as a parameter instead of the inclusion in a fixed method name? If XPages doesn't find getSomeField(), will it try something else instead, e.g. just get(String name) or so?
As always: I really appreciate your help and answers!
The way the binding works depends on whether or not your Java object implements a supported interface. If it doesn't (if it's just some random Java object), then any properties are treated as "bean-style" names, so that, if you want to call ".getSomeField()", then the binding would be like "#{obj.someField}" (or "#{obj['someField']}", or so forth).
If you want it to fall back to a common method, that's a job for either the DataObject or Map interfaces - Map is larger to implement, but is more standard (and you could inherit from AbstractMap if applicable), while DataObject is basically an XPages-ism but one I'm a big fan of (for reference, document data sources are DataObjects). Be warned, though: if you implement one of those, EL will only bind to the get or getValue method and will ignore normal setters and getters. If you want to use those when present, you'll have to write reflection code to do that (I recommend using Apache BeanUtils).
I have a post describing this in more detail on my blog: https://frostillic.us/f.nsf/posts/expanding-your-use-of-el-%28part-1%29