Talking through some current issues with ColdFusion Event Gateways
ColdFusion, Technology, JavaOn a project that I am currently engaged in I am leveraging ColdFusion Event Gateways which work as a subscriber to a SonicMQ JMS server. My gateway instance listens for messages on the ESB (Enterprise Service Bus) on a particular destination name (topic/queue). When it receives a message, it parses the XML that it received, and plays traffic cop pushing data into various services that need it. I have this working flawlessly in my small development environment. However, I have a couple of complexities ahead of me that I am having difficulty coming up with a good solution.
- Running in the cloud - Our production environment will have any number of CF instances, not clustered, but rather running as isolated applications with a load balancer directing the requests using sticky sessions. Our system will be bringing new instances on/off line as traffic traffic dictates. I have yet to solve the issue of how to set up my JMS Event Gateway in this environment. I definitely don't want 20 different listeners out there all doing the same work. I have considered the idea of having some sort of a support database where a listener can insert a row with a specific JMS message ID and when any other server picks up a message with that ID it will see that it is already being acted upon and it can safely ignore it. There are a couple of negatives that I can see right off the bat. First is that every single subscribed instance will have to pull in the same message and test to see whether or not it should be acted upon. It just seems like a little bit of redundancy that shouldn't be there. Secondly, there is a chance that two servers could pick up the same request within milliseconds of each other and both could end up doing the work. Duplicate processing could not only be wasteful, but could also create some data integrity issues.
- Different environments have different settings (dynamic config) - Right now in our development phase, we have a single config file with setting specific to our development JMS server (credentials, domain, URL, Initial Context Factory, etc). However, soon I will need to have this process support a number of different environments: multiple dev environments, multiple integration environments, multiple QA environments, and eventually production. Ideally it would be wonderful if I could find some way to load a specific config into the event gateway at server init time, but as of today I have _NO_ idea how to solve this one. First, there is no real intrinsic indicator at the server level that lets it know what environment is currently running (yet anyway...) and secondly, ColdFusion event gateway architecture isn't conducive in any way to dynamically loading a specific config.
Add Comment
Strange behavior with ColdFusion ExpandPath() when using Symbolic Links
ColdFusion, Technology, LinuxI was playing around with the Quicksilver framework last night, and for some reason it was unable to find and instantiate my CFCs properly. After digging into the framework a bit and determining where it was breaking, I discovered something strange about the way that ColdFusion interprets ExpandPath() when it exists in a directory that is defined as a symbolic link. I am not sure if the same behavior exists on Macs, but I would imagine it does. If someone could confirm that to be the case, I would be interested.
For starters, I usually have a 'www' directory in my user home directory. This way when I pass my user profile around from distro to distro, my development work is included in my home directory. For ease of configuration I typically have a symbolic link in my OS that points /www/ ---> /home/dshuck/www/. Then when I am creating a new web project called 'davescode', I would put it in /home/dshuck/www/davescode, but my Apache config would usually point to /www/davescode. For the past several years, this approach has worked will for me. That is until last night when experimenting with Quicksilver.
When Quicksilver loads, it creates a list of service CFCs in the the application in such a way that if I had Foo.cfc in a directory 'com' in the root of my davescode site, it would look like /home/dshuck/www/davescode/com/Foo.cfc. When I initted the application, I was getting an error that it couldn't find the CFC home/dshuckcom/Foo.cfc. Essentially what was happening is that it was getting the full path of the CFC and replacing the path to the root of the site with "". In a perfect world the value of the path after the string replace would have looked like com/Foo.cfc. Unfortunately that was not so. Here's why!
I put a test file called path.cfm in the root of my davescode site that considted of the following:
<cfoutput>#ExpandPath("./")#</cfoutput>
<br/>
<cfoutput>#ExpandPath("/")#</cfoutput>The result was very surprising!
/home/dshuck/www/davescode/ /www/davescode/
For some reason when you do ExpandPath("/") it looks at the symbolic link path, but when you do ExpandPath("./"), it looks at the true file path. For the life of me, I can't think of why that would be. If anyone has an explanation, I would be all ears!
Solving java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.
ColdFusion, JavaRecently I have began working with JMS and ColdFusion, in which we are building a system that subscribes to an enterprise JMS server and picks up messages relevant to its needs and acts on them. I had my proof of concept working with the open source Apache ActiveMQ server and was very pleased with the results. However, in our production environment, the powers that be decided to use the very non-free SonicMQ server.
As I tried to convert the event gateway over to the SonicMQ server, it failed on initialization with the following exception:
javax.naming.NamingException [Root exception is java.lang.SecurityException: Seed must be between 20 and 64 bytes. Only 8 bytes supplied.] at com.sonicsw.jndi.mfcontext.MFConnectionManager.connect(Unknown Source) at com.sonicsw.jndi.mfcontext.MFConnectionManager.<init>(Unknown Source) at com.sonicsw.jndi.mfcontext.MFConnectionManager.getManager(Unknown Source) at com.sonicsw.jndi.mfcontext.MFContext.<init>(Unknown Source) at com.sonicsw.jndi.mfcontext.MFContextFactory.getInitialContext(Unknown Source) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.init(InitialContext.java:223) at javax.naming.InitialContext.<init>(InitialContext.java:197) at examples.JMS.JMSConsumer.start(Unknown Source) at examples.JMS.JMSGateway.startGateway(Unknown Source) at coldfusion.eventgateway.GenericGateway.start(GenericGateway.java:118) at coldfusion.eventgateway.EventServiceImpl$GatewayStarter.run(EventServiceImpl.java:1428)
In my research on this problem, I found several people reporting similar errors, each on CF8, and each talking to 3rd party tools. Eventually I found the solution through an email discussion between one of the developers in my company and an Adobe developer. Apparently in CF8, they added FIPS security, which disables the Sun JCE (encryption libraries). To solve this error, you need to add the following line to your java.args in your jvm.config file in JRun.
-Dcoldfusion.disablejsafe=true
Now restart your server and try again!
Making your application flow obvious in Mach-II with event-mappings
ColdFusionI recently joined a company that makes use of Mach-II in a few applications. Some of them were created as the developers were learning the framework and employ some obvious un-best practices. The team is made up of people from various skill levels, but I have noticed that about half of the team just absolutely cringes when they hear "Mach-II". They talk about how difficult it is to troubleshoot and how it is next to impossible to follow application flow. I was very surprised to hear that response, because I think one of the big benefits of using Mach-II is that I can look at a config XML and read the story of my application. I will touch on this in more detail in a bit.
So the other day I had my first experience digging in deeply into one of they apps to solve a problem... and it took me forever to figure out where the hell anything was. I started on the default home event, which only had a filter that announced other events, that had listeners that announced other events and so on until I was *EIGHT* events deep. In each one of these announcements, I had to go find the listener/filter, look into the methods, and search for where I might be going next. It suddenly became overtly clear why the other developers hate Mach-II.
Now, back to why my config files tell a story... first of all, I can't think of many cases where an app needs to announce 8 events before it gets to a destination. However, troubleshooting this would have been so much simpler if only the developer had been clear in the XML using event-mappings. As a rule, if I ever alter the flow of my application from within a filter/listener, I always have an event-mapping that shows this in my config. That way I can quickly skim the XML and know what possible exits I have. In most cases, it should be pretty obvious where you are going based on that alone, and you don't even need to open the CFCs to figure it out. Although I certainly do use event-mapping for aliases, more often than not they will look like this:
<event-mapping event="SomeEvent" mapping="SomeEvent" />
It serves no actual functinal purpose other acting as a means to document the flow. Does anyone else use the practice? How do you keep the application flow obvious in your configuration files?
I was talking to Aaron Lynch about this (who uses the same practice) and from that conversation I decided I would open this up for conversation. What I would love to see is some type of optional setting in Mach-II that would enforce this so that all developer on a team had to use this methodology. Maybe something along the lines where when an event is announced from within a CFC and it hasn't been mapped in the XML it would barf up an exception?
I have no doubt that some people will hate this idea. However, in the bigger picture I would like to see less people hating frameworks, and if we can make things more clear from a troubleshooting/maintanence perspective, I think that there would be less FUD!
Any thoughts on this?
Interfaces in ColdFusion - I think I have finally come around on CFINTERFACE
ColdFusionI will admit it...
When all the pre-ColdFusion 8 debate was swirling about whether or not to add interfaces into CFML, I didn't really get it. It's true. The only OOP I had ever really done was in CFML, ever having experienced how interfaces really come into play, and I think I fell into the the easy path of considering it worthless because I didn't take the time to understand it. So very quietly, I was in the "we don't need it!" camp.
Much has changed for me as a developer since that time. I have gotten quite comfortable in Flex development, and working with Flex made me realize that Java is not really all that difficult to grasp for me now, and I am pretty comfortable getting around there too. I have begun playing a bit with Groovy as well, so I have been exposed to much more since there actually *was* a debate about interfaces.
So now that debate has long since died, and the pro-interface crowd won - and then immediately decided that they didn't actually need interfaces after all - I realized yesterday that I finally get it!
Before I go any further, I would like to give my definition of an interface, because I am sure there are still plenty of CF developers who are where I was just a short time ago with just a very loose grasp, if any, on the concept. In fact, I am not sure that I am much beyond a loose grasp, but I will do my best to explain. For those who already know all this, just bear with me here.
In talking about interfaces with another developer on my team yesterday he asked how they are used. Half joking, I replied "They aren't! They don't *do* anything at all". What I meant by this is that you don't ever actually call an interface and your application never actually asks an interface to do anything. The interface exists simply to enfore rules in your data model. In essence it is a zero-tolerance "Object Gestapo" that makes sure that no one ever gets out of line. An interface is truly little more than a contract that says "Any object that implements me must contain the things I define". In essence, I suppose you could think of it as a shell CFC that defines methods, arguments, and return types, that you can't actually call. If I then define a CFC that implements that interface, it better damn well adhere to it strictly or the object gestapo comes down on you hard!
So why this extra work right? CF is a loosely typed language. Its status as an OOP language has been debated. However, the fact of the matter is that most of the top slice of CFML developers are writing some really amazing object oriented applications. Due to this, some of the more strict products from languages like Java might actually have some place in our work.
Let me give a real world solution that might help solidify my swirling thoughts on the matter. to give background on the environment I am working in, I recently began working for a relatively large insurance provider. Counting another 17 developers that are just being moved into ColdFusion from other languages, we have one of the larger ColdFusion development groups that I am aware of in my area. Many of the developers work remotely, and we have several that are in other states. Due to this, communication must be clear to keep everyone on the same page.
A current project that is in the works is to move our entire policy system off of one third-party vendor to another. The APIs between the two are vastly different, however, we still need the same data available to us in our applications. To make things more complicated, we will be moving one state at a time. So effectively there will be two distinctly different policy systems in play until the last state is converted.
My architectural approach to solving that problem is to use a PolicySystemFactory that returns the appropriate PolicySystem to me based on specific business rules. Any PolicySystem will actually serve as an adapter to the specific API of its third-party system, but the methods that the PolicySystem object exposes to the application *must* be consistent. The application shouldn't really care which system it is talking to as long as the system is giving it the right data and doing taking the right action on data that is passed in.
How do we ensure that we have the exact same API for not only the two current policy systems, but any future policy systems that we don't even know about yet?
Well, we could just make sure all developers know about it, and write it in some document hundreds of pages long that no one ever reads. Then after both of those things fail, the developers will eventually figure it out as the application pukes in different areas as it is getting data in different shapes than it is expecting, or as it tries to use methods differently than the PolicySystem is expecting. Eventually they will work this out.
Or... You could do both of the above items (communicate & document) and save everyone a lot of trouble by establishing that any PolicySystem *must* adhere to rules established in an interface. By taking this approach, there is no question whatsoever that the PolicySystem will not break your application by working differently than expected.
How do you implement this approach? (really.. I didn't mean it as a pun)
First, we would want to figure out exactly how a PolicySystem should be shaped. In our ultra-simplified example, a PolicySystem must have three methods: getPolicy(id) returning a Policy object, getPolicyAgent(Policy) returning and Agent object, and getPoliciesByStatus(StatusId) returning a structure of Policy objects
This is what our Interface would look like:
PolicySystemInterface.cfc
<cfinterface>
<cffunction name="getPolicy" access="public" output="false" returntype="Policy">
<cfargument name="id" type="numeric" required="true" />
</cffunction>
<cffunction name="getPolicyAgent" access="public" output="false" returntype="Agent">
<cfargument name="Policy" type="Policy" required="true" />
</cffunction>
<cffunction name="getPoliciesByStatus" access="public" output="false" returntype="Policy{}">
<cfargument name="StatusId" type="numeric" required="true" />
</cffunction>
</cfinterface>
As you can see above, we use the <cfinterface /> tag to define this CFC as an interface. We then write our functions much like we would in a <cfcomponent /> keeping in mind that whatever we define must be used *exactly* the same way by any object that implements it. So what would one of those objects look like? Here is our old legacy policy system object. Take a look at what is going on in line #1 in the <cfcomponent /> tag.
OldLegacyPolicySystem.cfc
<cfcomponent name="OldLegacyPolicySystem" output="false" extends="AbstractPolicySystem" implements="PolicySystemInterface">
<cffunction name="init" access="public" output="false" returntype="AbstractPolicySystem">
<cfreturn super.init("OldLegacyPolicySystem") />
</cffunction>
<cffunction name="getPolicy" access="public" output="false" returntype="Policy">
<cfargument name="id" type="numeric" required="true" />
<!--- NOTE - In real life, we would use a service to create this bean, not instantiate it here!!! --->
<cfset var Policy = CreateObject("component","Policy").init() />
<!---
########################################
In this area we would access policy info using the OldLegacyPolicySystem (however it does it!) and populate the Policy bean
########################################
--->
<cfreturn Policy/>
</cffunction>
<cffunction name="getPolicyAgent" access="public" output="false" returntype="Agent">
<cfargument name="Policy" type="Policy" required="true" />
<!--- NOTE - In real life, we would use a service to create this bean, not instantiate it here!!! --->
<cfset var Agent = CreateObject("component","Agent").init(arguments.Policy) />
<!---
########################################
In this area we would access Agent info using the OldLegacyPolicySystem and populate the Agent bean
########################################
--->
<cfreturn Policy/>
</cffunction>
<cffunction name="getPoliciesByStatus" access="public" output="false" returntype="Policy{}">
<cfargument name="StatusId" type="numeric" required="true" />
<cfset var PolicyStruct = {} />
<!---
########################################
In this area we would load Policies using the OldLegacyPolicySystem and build a structure of them
########################################
--->
<cfreturn PolicyStruct />
</cffunction>
</cfcomponent>
You should notice that we have:
extends="AbstractPolicySystem" implements="PolicySystemInterface"
Two things are happening there. First, we are extending an AbstractPolicySystem object that will hold common functionality among all PolicySystems. Ours looks like this:
<cfcomponent output="false">
<cffunction name="init" access="public" output="false" returntype="AbstractPolicySystem">
<cfargument name="SystemName" type="string" required="true" />
<cfset this.SystemName = arguments.SystemName />
<cfreturn this />
</cffunction>
</cfcomponent>
For our test case, when we instantiate our PolicySystem we can quickly prove which one we are dealing with by looking at PolicySystem.SystemName. That said, your application shouldn't know or care.
By adding the implements attribute we are ensuring that this PolicySystem plays by the rules we defined in our PolicySystemInterface. No "ifs" "ands" or "but"s!
So, this is the exercise that brought me around on CFINTERFACE. What are your thoughts?
Setting up Apache, OpenBD, Railo and ColdFusion - Part 4 - Installing Railo under Tomcat with Apache webserver
ColdFusion, ServersThis is Part 4 in an ongoing series demonstrating how to install OpenBlueDragon, ColdFusion, and Railo concurrently with all requests passing through the Apache webserver. You will find links to all parts of this series at the bottom under "Related Content"
In this post we will be building upon our existing environment in which we installed Apache webserver, Tomcat 6, OpenBlueDragon, and ColdFusion, by adding Railo to the mix. If you have been following along thus far, we are well past the hard stuff at this point. To install Railo, which is deployed as a java war file, we are going to repeat and slightly modify many of the steps that we took at the end of Part 2 when we installed OpenBD as a Tomcat web application.
Let's start by setting up our hosts entry so that our new site resolves to localhost.railo, and set up the Apache webserver to listen for the request. Open up /etc/hosts, and append 'localhost.railo' (without quotes!) to the line that begins with 127.0.0.1. Next we want to create a new virtual host file for the site under Apache. Do so like this:
$ cd /etc/apache2/sites-available
sudo gedit localhost.railo
Paste the following into that new file and save it.
<VirtualHost *>
ServerName localhost.railo
JKMount /* worker1
</VirtualHost>
As we learned in Part 2, the line "JKMount /* worker1" is instructing apache to pass everything to the worker we defined in /etc/apache2/workers.properties. That worker will then pass the request on to Tomcat port 8009, under which our application actually resides.
Now that we have defined this site, we want to make sure that it gets included on our next Apache restart. We do this by running the following:
$ sudo a2ensite localhost.railo
Site localhost.railo installed; run /etc/init.d/apache2 reload to enable.
At this point, we need to make sure there is a an application set up in Tomcat to receive our request. First, let's start by downloadingthe free Railo Server from their download page. Look toward the bottom of the page and download "Railo Custom" and download railo-3.0.2.001.war. (or newer version if it is there). Once we have the file downloaded, we will create a new directory for our application under Tomcat. We will then copy the Railo war file into it from our download directory. When we have the war file under /opt/tomcat6/webappas/localhost.railo/ we will extract it, and then safely delete the war file itself. These steps can be seen here:
$ sudo /opt/tomcat6/webapps/localhost.railo
sudo cp railo-3.0.2.001.war /opt/tomcat6/webapps/localhost.railo/
cd /opt/tomcat6/webapps/localhost.railo
sudo jar xvf railo-3.0.2.001.war
sudo rm railo-3.0.2.001.war
Since we now have the application in place, it is time to modify the Tomcat server config so that it knows to send the appropriate requests to it. Do the following:
$ sudo gedit /opt/tomcat6/conf/server.xml
Look for the section that we added previously for our OpenBlueDragon localhost site "localhost.bd". We are going to copy that section, modifying the "name" and "docBase" attributes to match our new application and paste it just below the localhost.bd site. When you are done they should look like this:
<Host name="localhost.bd" appBase="webapps" unpackWARs="true"
autoDeploy="true" xmlValidation="true" xmlNamespaceAware="false">
<Context path="" docBase="localhost.bd/" reloadable="true" privileged="true" antiResourceLocking="false" anitJARLocking="false" />
</Host>
<Host name="localhost.railo" appBase="webapps" unpackWARs="true"
autoDeploy="true" xmlValidation="true" xmlNamespaceAware="false">
<Context path="" docBase="localhost.railo/" reloadable="true" privileged="true" antiResourceLocking="false" anitJARLocking="false" />
</Host>
With all that done, we are ready to restart (or start) Apache, Tomcat and our new Railo site will be available at http://localhost.railo
So with our original goal of being able to run the three CFML engines, it's time to see how we did....
Loading....