Author:
Steve Brownlee
Mar
31
If any of your webapps aren’t implementing any of the new features in ColdFusion 7 that use the Flex components (CFFORM, CFDOCUMENT, etc.), then why would you need it to be part of the startup and, more importantly, the deployment. It’s just 5.5 megs of wasted space on your machine. Well, here’s how you stop ColdFusion from starting up Flex and removing it from the system.
Open up your trusty web.xml file for your webapp, and remove the following elements.
- The ./WEB-INF/cfform/jars path from
<context-param id=”macromedia_context_88″>
- Everything between the comments “start flex settings” and “end flex settings”
- The CFInternalServlet servlet mapping
- Servlet definition for macromedia_servlet_12
- Servlet definition for macromedia_mapping_13
- Any init-param attribute that references cfform-gateway-config.xml
Now that Flex isn’t referenced in the startup, your can delete the {your-app}\WEB-INF\cfform directory.
Filed under:
coldfusion, jboss
Author:
Steve Brownlee
Mar
16
While trying to get a site to render reports in Crystal Reports, moving to J2EE implementation required a few tweaks to the settings, but the information was scattered over a few files found on Macromedia’s site. Here’s what I had to do to make sure that CF could load the COM objects correctly.
- Add the ColdFusion lib path to the Java classpath. This most likely will be WEB-INF\cfusion\lib under your webapp.
- Add WEB-INF\cfusion\jintegra\bin and WEB-INF\cfusion\jintegra\bin\international to the java.library.path
- Add two arguments to the startup command: -DJINTEGRA_NATIVE_MODE and -DJINTEGRA_PREFETCH_ENUMS
- One additional step I had to take, most likely because this machine was the guinea pig for J2EE setup, was go through my Windows Registry and make sure all references to TypeViewer.dll were pointing to the right directory (I had moved my web-inf\cfusion directory to another location, so they weren’t synched up)
Hope that helps anyone else who is running Crystal on a J2EE server and has problems using it.
Author:
Steve Brownlee
Mar
13
While playing around with what components could, and could not, be deleted from the JBoss deploy directory and still have a working server, I eventually found that almost all of the built-in components can be eliminated.
Of course, your results may vary depending on your site architecture and other server-side technologies you’re using, but when I’m deploying just ColdFusion WAR/EAR files on JBoss, the only required directory is jbossweb-tomcat50.sar. I could delete all other files and directories from deploy. This has a good side effect of decreasing the deploy time from almost 2 minutes to ~20 seconds (on my system). Not a huge difference, but it’s always nice to streamline your deployment.
In addition, I was able to eliminate all of the JAR files from the jboss\client directory and most JAR files from server\default\lib (keeping only jboss, mail and logging JARs). No huge gains here other than saving some disk space.
Bottom line, don’t be afraid to streamline your server. Eliminate unneeded components, JAR files, archives and configuration files to have a clean, efficient deployment.