complex_model_out_of_memory_error

[GoogleCodeExporter]

What steps will reproduce the problem?
1.I have modified Person class
    public class Developer {
           private final String name;
           private final String lastName;
           private final String mail;
           private final Project projecttest;
2.run GenerateXMLFields or GenerateDocxReport
3.

What is the expected output? What do you see instead?

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOfRange(Arrays.java:3209)
    at java.lang.String.<init>(String.java:215)
    at java.lang.StringBuilder.toString(StringBuilder.java:430)
    at fr.opensagres.xdocreport.template.velocity.VelocityFieldsMetadataClassSerializer.getFieldName(VelocityFieldsMetadataClassSerializer.java:54)
    at fr.opensagres.xdocreport.template.formatter.AbstractFieldsMetadataClassSerializer.process(AbstractFieldsMetadataClassSerializer.java:133)
    at fr.opensagres.xdocreport.template.formatter.AbstractFieldsMetadataClassSerializer.process(AbstractFieldsMetadataClassSerializer.java:140)

What version of the product are you using? On what operating system?
xdocreport 0.9.6
operating system is windows 7 64 bit with 64 bit jvm (jdk1.6.0_25)

Original issue reported on code.google.com by orhu...@gmail.com on 9 Mar 2012 at 8:48

Attachments:

• xdocreport-quickstart-docx.rar

[GoogleCodeExporter]

Sorry I am wrong I have modified Developer Class 

Original comment by orhu...@gmail.com on 9 Mar 2012 at 9:01

[GoogleCodeExporter]

Hi orhunyz,

There is a bug with FieldsMetadataClassSerializer which computes FieldsMetadata 
from Java class 

(Developer#getProjecttest()).

This bug must be resolved. To avoid this bug (for the moment) you can fill 
fieldsmetada at hand like this : 

--------------------------------------------------------------
FieldsMetadata metadata. = report.createFieldsMetadata();
metadata.addFieldAsList("developers.Name");
metadata.addFieldAsList("developers.LastName");
metadata.addFieldAsList("developers.Mail");
metadata.addFieldAsList("developers.Projecttest.Name");
--------------------------------------------------------------

Regards Angelo

Original comment by angelo.z...@gmail.com on 9 Mar 2012 at 9:07

• Changed state: Accepted

[GoogleCodeExporter]

it solves my problem  thanks a lot for your helps

Original comment by orhu...@gmail.com on 9 Mar 2012 at 11:10

[GoogleCodeExporter]

sorry for my questions :)
if I change Project definition to List<Project> in Developer Class  how can
I use?

2012/3/9 orhun y�lmaz <orhunyz@gmail.com>

Original comment by orhu...@gmail.com on 9 Mar 2012 at 12:11

[GoogleCodeExporter]

That's it's a good question. You cannot use that for FieldsMetada. FieldsMetada 
manage simple case when you have a list (list of pojo) and not with complex 
graph list of pojo of list of...

But I'm not sure that's interesting because if you have :

developers.Projects.Name field you must set a start list between developers and 
Projects.

FieldsMetada is used for both thing : 

 * manage lazy loop in table.
 * generate fields.xml for MS Macro/OOo extension to help you to design the report.

So the goal is tu use FieldsMetada when it's possible to have those features. 
If you cannot use it you can use @before-row/@after-row (see 
http://code.google.com/p/xdocreport/wiki/DocxReportingJavaMainListFieldAdvancedT
able).

But for your case, I will do like this : 

1) FieldsMetadata 

FieldsMetadata metadata. = report.createFieldsMetadata();
metadata.addFieldAsList("projects.Name");

where "projects" key is computed in the docx report with #set. : 

-----------------------------------------
#foreach($d in $developers)

#set($projects = $d.Projecttest)

Here you insert the mergefield in a table : 
$projects.Name

#end
-----------------------------------------

Regards Angelo

Original comment by angelo.z...@gmail.com on 9 Mar 2012 at 1:36

[GoogleCodeExporter]

Gotcha :

I found the problem 
line 140 of "AbstractFieldsMetadataClassSerializer"
was
 process( fieldsMetadata, fieldName, clazz, listType );

changed to 
process( fieldsMetadata, fieldName, returnTypeClass, listType );

the previous code result in a infinite loop that end up with a OutOfMermoyError.

Original comment by pascal.leclercq on 13 Mar 2012 at 8:47

• Changed state: Fixed

[GoogleCodeExporter]

Many thanks Pascal.

Could you add it this issue on the features at 
http://code.google.com/p/xdocreport/wiki/XDocReport097

Thanks.

Regards Angelo

Original comment by angelo.z...@gmail.com on 13 Mar 2012 at 9:05

[GoogleCodeExporter]

Hi Pascal,
I found another problem if you use complex model it has class which is
using at subclass it gives out of memory error :D it is recursively call
upper class
for example Developer has Project  and Project has Developer. it maybe
silly example but if you want to use hibernate class it can be usefull this
type of variable definitions
if AbstractFieldsMetadataClassSerializer.process function has
classDeepLevel properties it will solve this type exceptions

Original comment by orhu...@gmail.com on 12 Jun 2012 at 10:22

[GoogleCodeExporter]

Hi Pascal,

Sorry, it is not required because xDocReport 0.9.8 it solves this problem.

Original comment by orhu...@gmail.com on 15 Jun 2012 at 5:43

[GoogleCodeExporter]

Hi,

>I'm a bit afraid of side effect but so far all the tests passes.
I'm afraid too when you tell that. Hope I had done enough JUnit.

>I'm thinking of using JAXB marshalled/unmarshaller instead besides the 
fields.xml >form.
Yes Pascal it's a good idea : having XSD instead of XML fields. But the big big 
problem is about the XDocReport OXT and MS Macro which consumes today XML 
fields. Parsing XML is more easy than XSD. Parsing XSD can be very complex (ex: 
<xs:include, complex XSD, etc...). I'm afraid with that.

>This would make huge changes in xdocreport but so far I think this would cover 
all >of our uses cases and this would rely on open standards.
I agree with that, but I think we should dupport the both (XML fields or XSD). 
I think before developping this XSD feature you should develop the OXT and MS 
Macro which consumes XSD to populate the treeview and I hope you will have no 
trouble with that. I would like avoid that you develop XSD feature for nothing 
(XML fields are used for OXT+MS Macro).

More I don't know how you will manage the key of the field name. 
For instance if you have 

------------------------------
Project p = new Project();
context.put("p", p);
------------------------------

You will have XML fields like this (for Velocity): 

------------------------------
<field name="p.Name" />
------------------------------

You will have XML fields like this (for Freemarker): 

------------------------------
<field name="p.name" />
------------------------------

DO you think it's possible with JAXB?

Regards Angelo

Original comment by angelo.z...@gmail.com on 15 Jun 2012 at 7:12