I was having an annoying problem of the descriptor file not automatically updating with any new servlets that i had created. Turns out i needed to create the project using Dynamic web module version of 2.5 rather that the default 3.1
The reason being is that Servlets 3.0 specification does not require a descriptor file, the details are contained within the class itself.
Tuesday, November 8, 2016
Monday, November 7, 2016
Tomcat manager's upload file size
I was having trouble deploying coldfusion to my tomcat server, it would just timeout without any kind of display on the browser.
When looking at the log i came across this error
Turns out all i needed to do was to increase the upload size in the webapps/manager/WEB-INF/web.xml file
When looking at the log i came across this error
SEVERE [http-nio-8080-exec-6] org.apache.catalina.core.ApplicationContext.log HTMLManager: FAIL - Deploy Upload Failed, Exception: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (283599102) exceeds the configured maximum (52428800)
java.lang.IllegalStateException: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (283599102) exceeds the configured maximum (52428800)
Turns out all i needed to do was to increase the upload size in the webapps/manager/WEB-INF/web.xml file
52428800 52428800 0<
Monday, December 3, 2012
Script Object: Replacing xpath xpressions in a template
I found this very useful post about an easy way of replacing xpath expressions in a template
http://blogs.adobe.com/mtg/2010/07/a_generic_way_to_use_template.html
I found this especially useful since I've been involved in a few projects that required us to create html templates that had dynamic values in them. Rather than having to create a custom component to do the mapping and replacing, I'm able to use this simple snippet of code in a script object.
http://blogs.adobe.com/mtg/2010/07/a_generic_way_to_use_template.html
I found this especially useful since I've been involved in a few projects that required us to create html templates that had dynamic values in them. Rather than having to create a custom component to do the mapping and replacing, I'm able to use this simple snippet of code in a script object.
Wednesday, November 2, 2011
Resources not appearing in workbench
If you are putting resources in the LC repository through the SDK, you'll notice that they don't appear in workbench. You can confirm that they are truly there by going to the address http://server:port/repository, and then to actually get the resource to appear in workbench follow these steps:
1 import com.adobe.repository.infomodel.bean.ResourceProperty;
1 import com.adobe.repository.infomodel.bean.ResourceProperty;
import java.util.Collection;
2. Use: Resource newResource = (Resource) infomodelFactory.newResource (not Resource newResource = (Resource) infomodelFactory.newImage(...) )
3. Add the following lines of code:
ResourceProperty rProperty=new ResourceProperty();
rProperty.setNamespace("System");
rProperty.setName("PRIMARY");
rProperty.setValue(“true”);
Collection rProperties=newResource.getResourceProperties();
rProperties.add(rProperty);
2. Use: Resource newResource = (Resource) infomodelFactory.newResource (not Resource newResource = (Resource) infomodelFactory.newImage(...) )
3. Add the following lines of code:
ResourceProperty rProperty=new ResourceProperty();
rProperty.setNamespace("System");
rProperty.setName("PRIMARY");
rProperty.setValue(“true”);
Collection rProperties=newResource.getResourceProperties();
rProperties.add(rProperty);
Labels:
API,
LiveCycle,
Repository,
SDK,
WorkBench
Friday, June 3, 2011
PDF to email friendly HTML
There is a service in LiveCycle to convert PDF files to HTML, and it the output looks pretty decent, but after looking at the html code, we realized that there were a bunch of DIVS and such that were added to the forms. This didn't work out to great as a solution for us, because we planned to place that html into an email, and with all the divs and such it would look horrible (since some email clients don't follow a standard). There were a few options in the service to try and manipulate the CSS and such, but nothing that gave a satisfactory result.
We noticed that when converting xdp to html, the best way to maintain structure was by using tables. Subforms convert to divs, however email clients do not always render divs properly, so we stuck to using tables to structure our forms and also to control the layout of our forms. However, the layout got messed up when we did the conversion, so the solution that we came up with was to use the renderHTMLForm service with the option of nostyles, and to add the styles in manually.
Essentially we noticed that all of the names of complex objects (objects containing other objects, ie subforms, tables, table rows) that we created in the form would be carried over into the created html, with some additions.
So if we have a table called Details, which was in a a subform called Content, it would be converted to a table with id=NContent_0.NDetails_0.
I'm not sure what the "N" denotes, but the 0 at the end is the index of the object, so if you have repeating elements, the index would be noted at the end.
At this point, ideally, we would have liked to user the renderHTMLForms to import a css file in to use, but it puts the styles inbetween the head tags, which again is not great for email clients. So instead we wrote a custom component to insert it the styles from the css to inline (there are lots of libraries to convert css to inline, sorry wouldn't be able to tell you which).
The issue at this point was to know where to put the styles. Thats where the ids come in and why we used tables to structure the form. We were able to style the different parts of the form by placing them in the tags, matching them up with the appropriate id's. We used a config file to map the styles to the id's to try and automate and reuse as much as possible.
Not as elegant as i would like, but unfortunately the only way that i could think of to resolve the issue.
We noticed that when converting xdp to html, the best way to maintain structure was by using tables. Subforms convert to divs, however email clients do not always render divs properly, so we stuck to using tables to structure our forms and also to control the layout of our forms. However, the layout got messed up when we did the conversion, so the solution that we came up with was to use the renderHTMLForm service with the option of nostyles, and to add the styles in manually.
Essentially we noticed that all of the names of complex objects (objects containing other objects, ie subforms, tables, table rows) that we created in the form would be carried over into the created html, with some additions.
So if we have a table called Details, which was in a a subform called Content, it would be converted to a table with id=NContent_0.NDetails_0.
I'm not sure what the "N" denotes, but the 0 at the end is the index of the object, so if you have repeating elements, the index would be noted at the end.
At this point, ideally, we would have liked to user the renderHTMLForms to import a css file in to use, but it puts the styles inbetween the head tags, which again is not great for email clients. So instead we wrote a custom component to insert it the styles from the css to inline (there are lots of libraries to convert css to inline, sorry wouldn't be able to tell you which).
The issue at this point was to know where to put the styles. Thats where the ids come in and why we used tables to structure the form. We were able to style the different parts of the form by placing them in the tags, matching them up with the appropriate id's. We used a config file to map the styles to the id's to try and automate and reuse as much as possible.
Not as elegant as i would like, but unfortunately the only way that i could think of to resolve the issue.
Labels:
LiveCycle,
pdf to html,
Process,
renderHTMLForm
Subscribe to:
Posts (Atom)