Coldspring stopped me cold..

We just recently upgraded to Coldspring 1.2 and it wasn't long before I came to a grinding halt the next time that I needed to restart my CF instance. I got the following error:

Object Instantiation Exception
An exception occurred when instantiating a Java object.
The class must not be an interface or an abstract class. Error: ''.

The error occurred in C:\websites\coldspring\beans\AbstractBeanFactory.cfc: line 253

Our beta system wasn't having the same issues, so I decided to look at what might be different in the two environments. I found that I was still on 8.0.0 (doh!). So I went to http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403277&sliceId=1 and upgraded.

That worked right? Wrong! Though it was good for me to get up to speed with the proper version, it did nothing in getting me back to productivity. I browsed some more on some blogs with pieces of the error message and came across a blog that seemed to think this error happend when some nulls were being thrown around when it expected actual values. I looked at this line in the loadFrameworkProperties method in Coldspring/beans/AbstractBeanFactory.cfc:

<cfset local.fileStream = CreateObject('java', 'java.io.FileInputStream').init(arguments.propertiesFile) />

... which caused me to look in the initial code or the AbstractBeanFactory.cfc file here:

<!--- ColdSpring Framework Properties --->
<cfset variables.instanceData.frameworkPropertiesFile
       = "/coldspring/frameworkProperties.properties" />
<cfset variables.instanceData.frameworkProperties
       = loadFrameworkProperties(ExpandPath(variables.instanceData.frameworkPropertiesFile)) />

So I looked for the .properties file in the /coldspring directory and found nodda. I plugged an empty file into the coldspring directory by the name of frameworkProperties.properties and I was back in business.

Hope this helps.

Blessings...

I shot the session...

I was reading across a couple of old blogs recently about the need to kill a session immediately rather than waiting for it to timeout. If you are using J2EE sessions, the session will be orphaned when the browser is closed but the session still lives on until it eventually times out according to the time set for your application. There may be a need to clear out some of those sessions when you're sure they are orphans. Maybe you have a user that is logging in from another workstation and would like to clear out the other session so that you don't have the same user logged in twice. Whatever your reason, there is a way to immediately clear out the session and still have the onSessionEnd execute in your Application.cfc. Try this little piece of code:

<!--- get the session id by working with the session tracker --->
   <cfset _sessionid =  '74306b9b10b4c354a8db101f73246434611b'/>
   <cfset  killSession(application.applicationname,_sessionid)/>
  
   <cffunction name="killSession" output="false"
         access="public" returntype="void">
       <cfargument name="appName" required="true" type="string" />
       <cfargument name="sessionid" required="true" type="string" />
     
       <cfset var st = 
        createobject("java","coldfusion.runtime.SessionTracker") />  
       <cfset st.cleanUp(arguments.appName,arguments.sessionid) />
         
   </cffunction>

If you do not have J2EE sessions enabled, you can call cleanUp(application.applicationName, _cfid, _cftoken).
Note: I haven't tested this one yet.

This will successfully remove that session. It will also execute any onSessionEnd code that you have to take care of any cleanup scripts that you have. This is an undocumented method of sessionTracker so use with caution knowing that things could change. I'm not sure if this works in versions before CF8. I would be interested in knowing, if someone would be so kind as to test it.

Blessings...

Undocumented Goodness

In working on a project the other day, I needed to allow users to interact with data in such a way that they were not tripping over each other. This led me down the path toward a proof of concept with monitoring sessions for a particular application. The problem is that when you "touch" the sessionScope methods it will reset the session timeout and keep dead sessions alive. This can be countered by calling the methods using reflection like so:

<cfset tracker=createObject("java","coldfusion.runtime.SessionTracker")>
<cfset sessions=tracker.getSessionCollection(application.applicationname)>
<cfoutput>
<cfloop item="loopSession" collection="#sessions#">
Idle Time:
#getSessionProxy(sessions[loopsession],'getTimeSinceLastAccess')#<br/>
</cfloop>
</cfoutput>

<cffunction name="getSessionProxy"
output="false" access="public" returntype="string">

<cfargument name="session" required="true" type="struct" />
<cfargument name="method" required="true" type="string" />

<cfset var _a = arrayNew(1)/>
<cfset var _sessionClass =
_a.getClass().forName("coldfusion.runtime.SessionScope") />

<cfset var _method = ''/>
<cfset var _value = ''/>
<cftry>
<cfset _method =
 _sessionClass.getMethod(arguments.method, _a) />
<cfset _value = _method.invoke(arguments.session, _a)/>
<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn _value />
</cffunction>

That works great and is very valuable data, but what if you need to find out what the session.idofuser is on one of those sessions or another session variable that you need access too? There really is no reflected function that gives you access to those variables without touching the session timeout. You could do sessions[loopSession].idofuser but that would trip the session. Even a cfdump of the sessions collection trips the session. I couldn't find this documented on blogs or anywhere else, but there is a new sessionScope method going by the name of "getValueWIthoutChange". This must be new in CF8. I'm guessing one reason it was added is for the server monitor which gives you access to this info without touching the session timeout. If you google this method, you get absolutely 0 results. When I saw that in the dump of the sessionScope class, I knew there was hope. Important to note too is that Java is very case sensitive. Notice that the W and I are capped in "WIthout". Typo that made it through? Anywho, my next challange was finding the correct casting and such to be able to pass a var into the reflected getValueWIthoutChange method from CF. I flailed on this for about a day before I took this to a co-worker that was a java guy in a past life. He had it nailed down for me in a 1/2 hour or so. Long story short, we ended up with a method that will allow you to get any session var without touching the sessions. This is a beautiful thing and opens up all kinds of possibilities.

<cfset tracker=createObject("java","coldfusion.runtime.SessionTracker")>
<cfset sessions=tracker.getSessionCollection(application.applicationname)>
<cfoutput>
<cfloop item="loopSession" collection="#sessions#">
Idle Time:
#getSessionProxy(sessions[loopsession],'getTimeSinceLastAccess')#<br/>
User ID:
#getSessionValue(sessions[loopsession],'idofuser')#<br/><br/>
</cfloop>
</cfoutput>

<cffunction name="getSessionValue"
output="false" access="public" returntype="any">
<cfargument name="session" required="true" type="struct" />
<cfargument name="key" required="true" type="string" />

<cfset var a = arrayNew(1)/>
<cfset var valueMethod =  ''/>
<cfset var value =  ''/>
<cfset var sessionClass =
a.getClass().forName("coldfusion.runtime.SessionScope") />

<cftry>
<cfset a[1] =
CreateObject("java","java.lang.String").GetClass()/>
<cfset valueMethod =
sessionClass.getMethod("getValueWIthoutChange",a) />
<cfset a[1] =
CreateObject("java","java.lang.String").Init(arguments.key)/>
<cfif findnocase(arguments.key,structkeylist(arguments.session))>
<cfset value = valueMethod.invoke(arguments.session, a)/>
<cfelse>
<cfset value = ''/>
</cfif>

<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn value />
</cffunction>

<cffunction name="getSessionProxy"
output="false" access="public" returntype="string">

<cfargument name="session" required="true" type="struct" />
<cfargument name="method" required="true" type="string" />

<cfset var _a = arrayNew(1)/>
<cfset var _sessionClass =
_a.getClass().forName("coldfusion.runtime.SessionScope") />

<cfset var _method = ''/>
<cfset var _value = ''/>
<cftry>
<cfset _method =
 _sessionClass.getMethod(arguments.method, _a) />
<cfset _value = _method.invoke(arguments.session, _a)/>
<cfcatch><!--- Do Nothing ---></cfcatch>
</cftry>
<cfreturn _value />
</cffunction>

Now, as an important note and as has been echoed on other blogs, this is an undocumented method and the farm should not be bet on it. There is no guarantee that it will live on in other versions of CF so use wisely.

With that said, praise God for technology and go change the world.

Blessings...

RegEx broke my phone

We had a bug turned in on a form that was not accepting valid phone numbers, or so it seemed. The number used was something like 233-122-2323. Looks like a valid phone number right? I dug into the form field and found that it was a cfinput tag utilizing the validate="telephone". We recently moved to CF8 and I was wondering if this was a CF8 issue that was somehow unique. I looked at the generated source in order to evaluate the resulting js that is used to validate the form on submit. That led me to this code:

//form element phone 'TELEPHONE' validation checks
if (!_CF_checkphone(_CF_this['phone'].value, true))
{
alert(_CF_this['phone'].value)
_CF_onError(_CF_this, "phone", _CF_this['phone'].value, "A valid phone number is required.");
_CF_error_exists = true;
}

We can find the code for _CF_checkphone buried in this file, depending on your instance:

\JRUN4\servers\[instance]\cfusion-ear\cfusion-war\CFIDE\scripts\cfform.js

Finding the function in this file revealed the regular expression that is being used to validate phone number.

/^(((1))?[,\-,\.]?([\\(]?([1-9][0-9]{2})[\\)]?))?[,\-,\.]?([^0-1]){1}([0-9]){2}[ ,\-,\.]?([0-9]){4}(()((x){0,1}([0-9]){1,5}){0,1})?$/

1-800-322-5544 or 220-122-2323 (the number used on the form)

Now I'm not a regex guru nor do I work with it every day, so color coding is a definite help for me. There are some nice tools out there that can help you test regex both pay and free. I've been playing with RegExBuilder (free) lately. It doesn't have all the bells and whistles like being able to switch the regex engine, but it works for what I need right now. Anywho, let's break this down:

**- the ? makes the 1 optional

**- this has to be a digit between 1 and 9, never 0

**- two digits that are between 0 and 9

**- any character that is not 0 or 1. Surprisingly, this allows non digits

**- two digits that are between 0 and 9

**- four digits that are between 0 and 9

So according to the test number that was entered in the test, it violates rule **.
The funny thing is that we could have entered anything else besides 0 or 1. I tested 701-B86-5566 and it worked. But anywho… I think this form is performing as expected, unless of course there are valid phone numbers with the ** being 0 or 1. I wouldn’t know where to find that info and a brief google session didn’t turn anything up. I gave up quickly because didn't feel like digging into that right now. I'll leave that up to a more ambitious person. But the question to be answered is whether or not this should be reported as a bug and request Adobe to fix that regex in CF8 to be more accurate on the [^0-1] test. Why not [2-9]?

Blessings...

Token Broken...

This summary is not available. Please click here to view the post.