JRun wsconfig error- Security alert: attempt to connect to JRun server from host

I was experimenting with the Railo 3.3 installer, which includes an IIS connector to Tomcat, which works really well.   Too well in fact!  When I ran it, it actually unmapped all my existing IIS ISAPI mappings to JRun and was sending all requests to Tomcat.

I decided the quickest fix to this would be to simply open up /JRun4/bin/wsconfig.exe and remap the sites that were no longer connected.  However, when I did this, I received the following error:

Could not connect to JRun/ColdFusion servers on host localhost.

Knowing perfectly well that I had an instance of JRun running, I went to the terminal to look at the standard out and saw this:

Security alert: attempt to connect to JRun server from a 10.252.11.207 host

In case that is too hard to read, it says: “Security alert: attempt to connect to JRun server from a 10.252.11.207 host”.   I suspect that because I am attached to a WIFI connection with an IP Address on 192.168.*, and then VPN’d into my company with a second address of 10.252.*, JRun assumes that the connection attempt is coming from outside the subnet.

I went digging through files in JRun4/lib and came across security.properties.  In this file, there is a default setting:

jrun.subnet.restriction=255.255.255.0
jrun.trusted.hosts=
jrun.subnet.restriction.ipv6=[ffff:ffff:ffff:ffff:0:0:0:0]

I altered that restriction  setting from “255.255.255.0″ to “*” like this:

jrun.subnet.restriction=*
jrun.trusted.hosts=
jrun.subnet.restriction.ipv6=[ffff:ffff:ffff:ffff:0:0:0:0]

Once I did this and restarted the server, I was able to use wsconfig without issue.  And my ACF sites are pointed to JRun, my Railo sites are pointed to Tomcat, and all is right in the world again.

NOTE: DO NOT DO THIS ON A PRODUCTION MACHINE!   If you do, I strongly recommend that it is a very temporary change.

CFML wishlist: All collections should extend Iterator

Have you ever really given a second thought to the fact that in ColdFusion/CFML you have to loop queries, arrays, and structures in completely different ways?   For example, in each of these things, we are essentially doing the same thing:

<!--- looping our query --->
<cfloop query="myQuery">
	<cfset doStuff() />
</cfloop>
<!--- looping our array --->
<cfloop array="#myArray#" index="i">
	<cfset doStuff() />
</cfloop>
<!--- or --->
<cfloop from="1" to="#ArrayLen(myArray)#" index="i">
	<cfset doStuff() />
</cfloop>

<!--- looping our structure --->
<cfloop collection="#myStruct#" item="i">
	<cfset doStuff() />
</cfloop>

In each of these cases, we are essentially doing the same thing, that being looping a collection that contains multiple items and acting on each iteration.  I have always liked the fact that the ColdFusion array can be converted to a Java iterator like this:

<cfset iterator = myArray.iterator() />
<cfloop condition="#iterator.hasNext()#">
	<cfset thisIteration = iterator.next() />
	<cfset doStuff() />
</cfloop>

However, given the fact that <cfloop array=”#myArray#” index=”i”> is already an abstraction, it doesn’t make sense to use this in most cases.   But wouldn’t it be cool if you could call myQuery.iterator() or myStruct.iterator() and have the same functionality?  Or even better, why not have those collections all extend an iterator class so that it could be simplified even futher with myQuery.hasNext() or myStruct.hasNext().

Keep in mind, this discussion is only coming from the perspective of the programming interface itself, and I am not going to get into the differences behind the scenes of how a query result is actually a set of arrays of columns, or how an array differs from a struct.  My point is simply that if we have these abstractions, it sure would be cool if they were consistent, but we were still able to call specific functions on them like ArrayFind() , StructDelete(), etc.  If we had this ability, our loops in CFSCRIPT would be a lot more consistent as well.

With that said…. I will leave you with my wishful implementation for writing loops in CFML:

<cfloop condition="#myQuery.hasNext()#">
	<cfset thisRow = myQuery.next() />
	<cfset doStuff() />
</cfloop>

<cfloop condition="#myArray.hasNext()#">
	<cfset thisItem = myArray.next() />
	<cfset doStuff() />
</cfloop>

<cfloop condition="#myStruct.hasNext()#">
	<cfset thisItem = myStruct.next() />
	<cfset doStuff() />
</cfloop>

ColdFusion 9 catch() is not thread-safe!

I almost hate to admit this… no, I really hate to admit this.   For some reason, I was have always been under the impression that when you do a catch() in CFSCRIPT, that the variable you define as the catch is protected within the catch condition.   However, it hit me today that it is written to the variables scope by default.  Not only that, as I was testing it further, I believe that I have discovered that it is not thread-safe at all!   (edit: this problem applies to CFCATCH too. See notes at bottom and in comments)

Want to test this?  Open up a dummy CFM file and run the following:

(edit: I have modified this example since originally posting, putting the try/catch within a method so that it is consistent with the other examples)

WriteDump(ourFunction());	

public void function ourFunction()	{
	try	{
		local.a = b;
	}
	catch( any e )	{
		killE();
		WriteDump(e);
	}
}

public void function killE()	{
	StructDelete(variables,"e");
}

In case what we are doing isn’t abundantly obvious, we are creating a forced exception by referencing variable “b” which doesn’t exist.  In the catch(), we are saving the exception structure as variable “e”  so that we can handle however our business rules dictate.  In the case of our example, we are calling a method called killE(), and as you see it deletes “e” from the variables scope of the current template.  In the following line in catch() we are going to dump out exception details.  However, rather than a nice exception telling us that “b” wasn’t defined, we get the following:

ColdFusion exception

So, all we need to do is change “e” to “local.e” right and it will be thread-safe right?

WRONG!

This is apparently invalid syntax in Adobe ColdFusion (as of v.9).  Take this example:

WriteDump(ourFunction());	

public void function ourFunction()	{
	try	{
		local.a = b;
	}
	catch( any local.e )	{
		killE();
		WriteDump(local.e);
	}
}

public void function killE()	{
	StructDelete(variables,"e");
}

When we run this example, the following occurs:

What?!  So apparently we have to use the “var” scope to define our exception then, right?  So how about this attempt… this should do it, right?

WriteDump(ourFunction());	

public void function ourFunction()	{
	var e = "";

	try	{
		local.a = b;
	}
	catch( any e )	{
		killE();
		WriteDump(e);
	}
}

public void function killE()	{
	StructDelete(variables,"e");
}

WRONG!

If we take this approach, we receive the following:

My impression of this exception is that it is trying to write a variable into the variables scope that is already defined in the var scope and barking about it.

So then, what are we left with?

I am admittedly not the sharpest crayon in the box, but to me this indicates that catch() is 100% not thread-safe!   If anyone sees any problem with this diagnosis that I have made or has any thoughts, I am all ears.  If this is true, this throws huge wrenches into my work, and I am sure it does to others as well.

EDIT: As has been pointed out by Henry, this is an issue that Adobe was notified of this bug July of 2010 – almost 16 months!  It affects at least versions 8 and 9, and is not limited to CFSCRIPT.  It apparently affects CFCATCH as well.  I have looked through the tech notes of ColdFusion 9.0.1 Cumulative Hot Fix 1 and ColdFusion 9.0.1 Cumulative Hot Fix 2 and find no evidence that they have ever addressed it.

EDIT (again): I have tested this in both Railo and OpenBD.  OpenBD, due to the fact that it puts variables within methods in the var scope by default does not fail on the first test.  Railo, does fail.  However by using the variables scope like ColdFusion.  However, it allows you to do catch( any local.e ) and var scope e ahead.  So in a nutshell, ColdFusion is the only engine that does not give us any way to do thread-safe error handling.