I have an enterprise service with both a user exit class and an XSL map. Is there a way to write to the logs the actual XML of erData (StructureData object) used in the exit class? I have tried erData.toString(), but that writes
[Document: No DOCTYPE declaration, Root is [Element: <fw:root [Namespace: http://www.ibm.com/maximo]/>]]
to the log, not the XML.
According to the JavaDocs for Maximo 7.6, StructureData.getData() will return an instance of org.jdom.Document, on which, according to the JavaDocs for JDOM 1, you should be able to call toString() to return "a String representation of the Document, suitable for debugging."
Blessings!
erData.getDataAsString() will do it.
Related
I recently changed my domain objects from LocalDate to ZonedDateTime. I also created a brand new play JHipster application and one play entity choosing ZonedDateTime for two class members. The test application (new) works while my existing application does not, even after going through all the code twice. I loaded CSV data using Liquibase and my listing code shows the dates properly. Here's what the data looks like in my Maven output, e.g. entrydate='2017-02-23T19:53:18-05:00[America/New_York]', transaction='Initial Balance',
When I choose to update the date-time value with the "datetime-picker" in the dialog.html, a string date time is shown in the text box but when I push "Save" I get an "Internal Server Error" and the Maven output shows:
.HttpMessageNotReadableException: Could not read document: Text '2017-02- 26T00:53:18.000Z' could not be parsed at index 23 (through reference chain: org.ciwise.blackhole.domain.GenLedger["entrydate"]); nested exception is com.fasterxml.jackson.databind.JsonMappingException: Text '2017-02-26T00:53:18.000Z' could not be parsed at index 23 (through reference chain: org.ciwise.blackhole.domain.GenLedger["entrydate"])]
Does anyone have an idea why the picker would produce String text in the text box that isn't acceptable when the HTTP PUT occurs (edit)?
My application does use Service classes but they handle the same Java domain objects as the JPA Repository classes do.
One more thing, the schema for the API shows e.g. "entrydate": "2017-02-23T21:44:04.859Z", but the actual JSON return is "entrydate": "2017-02-23T19:53:18.000-0500",
I'm hoping someone else has encountered this before.
Thanks
David
The answer here was to re-introduce application.yml. Inside this file it defines some Spring profiles but of most importance, it provides an option for Jackson serialization into JSON e.g.
jackson:
serialization.write_dates_as_timestamps: false
This resolved my issue.
I'm generating a jaxws client based on webservice. Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
However if I try to link the boolean (e.g. isOptional()) to a checkbox, it will throw the following exception:
value="#{property.optional}": Property 'optional' not readable on type java.lang.Boolean
My google skills have informed me that jsf works fine with:
boolean isOptional()
boolean getOptional()
Boolean getOptional()
But not with
Boolean isOptional()
However it is not feasible to update the beans manually due to the size and amount of the webservices, so is there any way to make jsf use the java.lang.Boolean isOptional() properly? Or can I somehow define a property in the jaxb bindings file at generation time which magically generates "getOptional()"?
On a sidenote, the following does work:
<h:selectBooleanCheckbox value="#{property.isOptional()}"/>
However I can't actually update the value presumably because it can't find the setter.
EDIT: I'm running the latest jdk 7, the output of "java -version":
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) Client VM (build 23.1-b03, mixed mode, sharing)
The output of "wsimport -version":
JAX-WS RI 2.2.4-b01
Generated code:
public Boolean isOptional() {
return optional;
}
Jaxb will generate booleans using the java.lang.Boolean instead of the primitive type. In addition to this, it will generate the is() naming convention for beans.
Using the is getter prefix for java.lang.Boolean was a known major mistake of JAXB. It has been fixed in version 2.1.13 which was released April 2010 already. Keep your libraries up to date.
See also this blog article for some background.
The Great JAXB API Blunder
September 15, 2006
You've got to hand it to Sun for screwing this one up. It's one thing to write software that doesn't adhere to a specification when the documentation is as thick as a textbook. Take, for example, just about anything created by the W3C. However, it's really bad when it is your own spec that you can't follow, especially when it is the most well known part of it. That's right, Sun missed by a mile on their own spec when they created the JAXB 2.0 API. The JAXB 2.0 compiler (XJC) incorrectly uses the prefix "is" rather than "get" when generating the getter method for a java.lang.Boolean property. While the JavaBean spec states that read methods for primitive booleans can use the alternate "is" prefix, this flexibility does not extend to its boolean wrapper counterpart.
8.3.2 Boolean Properties
In addition, for boolean properties, we allow a getter method to match the pattern:
public boolean is();
This "is" method may be provided instead of a "get" method, or it may be provided in addition to a "get" method. In either case, if the "is" method is present for a boolean property then we will use the "is" method to read the property value.
An example boolean property might be:
public boolean isMarsupial();
public void setMarsupial(boolean m);
Given that JAXB is a code generation framework, and the idea behind code generation frameworks is that the code is to be used "as is" and not modified thereafter, this is a pretty big "oops". While this issue has been reported, the response from Sun is "sorry, its too late".
This behavior is governed by the spec, and unfortunately it's just too late for the spec to change now.
In terms of the user experience, thanks to auto-boxing, I don't think this will be a real issue for people. Is the problem that you are using Introspector and it's missing the property?
Too late? Not a real issue? It's BROKEN. FIX IT! I also don't like the naive statement that it probably won't affect frameworks. Um, yes it will, considering other projects did happen to adhere to the spec (hibernate, spring, myfaces, etc.)
UPDATE: Stevo Slavic informed me that this has been fixed in JAXB 2.1.13. See JAXB-131 for details. Yeah!
JSF/EL is not at fault here. It's doing its job properly conform the JavaBeans spec.
I'm not sure why the latest and greatest JAXB version still generates the wrong method but I finally fixed it by adding "-B-enableIntrospection" (as per http://jaxb.java.net/2.2.4/docs/xjc.html) to the wsimport call. This results in:
public Boolean getOptional() {
return optional;
}
I'm working against a very large API, most of whose return values look like:
<{APIMethodName}Resp>
<ResponseCode></ResponseCode>
<ResponseMessage></ResponseMessage>
</{APIMethodName}Resp>
Is there any sort of JAXB fu that will let me do this with just one class? I'm ok if JAXB ignores the root, just throws it away.
Thanks.
You could use the unmarshal method that take a class parameter. This causes the JAXB implementation to ignore the root element.
I'm using db4o with groovy (actually griffon). I'm saving dozen of objects into db4o objectSet and see that .yarv file size is about 11Mb. I've checked its content and found that it stores metaClass with all nested fields into every object. It's a waste of space.
Looking for the way to avoid storing of metaClass and therefore reduce the size of result .yarv file, since I'm going to use db4o to store millions of entities.
Should I try callConstructors(true) db4o configuration? Think it would help?
Any help would be highly appreciated.
As an alternative you can just store 'Groovy'-beans instances. Those are compiled down to regular Java-ish classes with no special Groovy specific code attached to them.
Just like this:
class Customer {
// properties
Integer id
String name
Address address
}
class Address{
String street;
}
def customer = new Customer(id:1, name:"Gromit", address:new Address(street:"Fun"))
I don't know groovy but based on your description every groovy object carries metadata and you want to skip storing these objects.
If that is the case installing a "null translator" (TNull class) will cause the "translated" objects to not be stored.
PS: Call Constructor configuration has no effect on what gets stored in the db; it only affects how objects are instantiated when reading from db.
Hope this helps
Basically, I have some models which all use JAXB. However, I have some highly custom functionality to convert to JSON and back so I want to write my own MessageBodyReader/Writer to do the job for me.
Right now, the writing portion is done: if i return one of my models from a REST resource, it goes through my writer. But when I try and accept a model as a FormParam, it doesnt use my MessageBodyReader and instead attempts to unmarshal it using JAXB (which fails).
So how I can tell Jersey to use my Reader instead?
public TestModel testProvider(#FormParam("model") TestModel input){ //doesnt work
return new TestModel(); //this part works!
}
Mark as #Provider
Add the configuration to your web.xml EX:
<init-param><param-name>com.sun.jersey.config.property.packages</param-name> <param-value> your.package.that.contains.the.provider </param-value> </init-param>
Since your writer works, but your reader does not, I'm guessing you have just missed something in your configuration. Some things to check:
Do you have the #Provider annotation on your reader?
Did you correctly implement the isReadable method on your reader?
Do you have the appropriate #Consumes annotation on the reader, does its media type match the media type specified on your service method?