Some CFML code that doesn't work

G'day:
I was sitting at Lord's yesterday watching England v NZ (and, um, we'll have no comments about that, thank-you very much), and a sudden thought popped into my head "Adam Presley might've been onto something there... if I leverage that....I wonder if I could get that code down to one statement?"

And that of course will mean nothing to anyone.

Lucee seems to mess up boolean expressions (kinda)

G'day:
Another bloody stumbling block writing this code (see CFML / Lucee: beware of "optional" semi-colons for the first one). This time Lucee's not getting the result of a OR expression right. Seriously. Well: I guess not as right as I'd like it to.

CFML / Lucee: beware of "optional" semi-colons

G'day:
Not what I had in mind writing up today, but as often is the way... the easiest way to find bugs in CFML is it try to use it.

Random PHP (7) bits: improvements to generators

G'day:
I was gonna have a look at output buffering in PHP today, but my attention has been hijacked by PHP 7. So instead I'm gonna have a look at some enhancements they've made to generators in 7. I'm actually not at work today, so there's a chance I'll be able to write both articles anyhow. We'll see.

Random PHP bits: __debugInfo()

G'day:
This is not a very insightful article, but I just happened to stumble across this functionality, and found it moderately interesting. This is another one of these "PHP n00b" articles, so if you're a seasoned PHP person, you'll not be reading anything here you don't already know.

Lucee CFML: import and application-set mappings (kinda redux)

G'day:
This is a like a sequel to "Railo bug? Or ColdFusion bug...". That article details how ColdFusion will kind of allow import to use mappings set in Application.cfc, provided an include uses said mapping first. On RailoLucee they stick closer to the docs (that's the ColdFusion docs, not the Lucee docs):

Attribute: taglib
Optionality: required
Description: Tag library URI. The path must be relative to the web root (and start with /), the current page location, or a directory specified in the Administrator ColdFusion mappings page.

My emphasis.

The Lucee docs make no claim about this one way or the other, but that's how Lucee behaves. In short, on Lucee one cannot use Application.cfc mappings with an import statement like that.

Getting PHP 5.x & 7-dev running on Windows/Apache

G'day:
Yesterday evening I discovered there are runnable versions of PHP 7-dev for Windows. I'd looked around for them before, but didn't spot them. Maybe they're new. I'm really struggling to get myself as far into the PHP loop as I am in the CFML one. Admittedly mostly due to lack of really trying.

Anyhow, I downloaded it and installed it (read: unzipped it), and indeed it seemed to a) work; b) do stuff PHP 5 can't do and PHP 7 is supposed to be able to do. So I figured "yeah, OK, so I do have PHP7 running". I'll write that lot up later on, once I have a decent play with it.

All my experiments last night - which were brief as I was at the bar @ LHR awaiting a flight - were running stuff via the CLI. This is fine with PHP but not how I'm used to doing stuff. Given I'm from a CFML background I'm used to running my test code in a browser, not a prompt, so I decided to get PHP7 running on Apache today. I've just managed to get it co-habitating with PHP 5. Win.

Here's what I had to do...

The Fork

Sourced from Ryan Mueller

CFML: what manner of object should an Exception be?

G'day:
Just before I commence a discussion on the Lucee Language Forum, I thought I'd do a code sample and ask what people think.

The question is stated in the subject line: "what manner of object should an Exception be?"

Lucee 5: using a Java class file

G'day:
Here's one that bit me on the bum with Lucee, and took me a while to sort out. Not least of all because of some... err... communication challenges I had along the way trying to get help on the issue. I'll get to that.


One of the most convenient features of ColdFusion for me - a dedicated CFML programmer and only an occasional Java hacker - is that on those rare occasions I do need to knock together some quick Java functionality, all I need to do is to write a quick class (although there's nothing quick about me and "writing Java classes"), sling it into the /WEB-INF/classes directory, and then I could just create instances of said class from CFML. I use this for "my" ClassViewer class which has proven invaluable to me over the last decade or so when trying to work out WTF is going on with CFML's interaction with Java. On any of my CFML servers one of the first things I do is chuck a copy of that ClassViewer.class into /WEB-INF/classes, and then it's there when I'm shufti-ing around:

// cv.cfm
cv = createObject("java", "ClassViewer");
try {
    1/0;
}catch (any e){
    writeOutput("<pre>#cv.viewObject(e)#</pre>");    
}

Easy. Oh, and this gives stuff like this:

public class coldfusion.runtime.DivideByZeroException
 extends coldfusion.runtime.ExpressionException
 extends coldfusion.runtime.NeoException
 extends java.lang.RuntimeException
 extends java.lang.Exception
 extends java.lang.Throwable
 extends java.lang.Object
 extends {
 /*** CONSTRUCTORS ***/
 public coldfusion.runtime.DivideByZeroException()


 /*** METHODS ***/
 public int getErrNumber()

 public final void setLocale(java.util.Locale)

 public java.lang.String getMessage()

 // [...]

(full output in this Gist: https://gist.github.com/adamcameron/fd5ab8db7c534acc68ac).

It's just easy. And has always "just worked".

Until Lucee 5, that is.

For reasons as yet unexplained coherently & honestly by Lucee, this functionality no longer works.

Fortunately the solution is easy... one just needs to stick the class in a JAR file and pop it in the /WEB-INF/lib directory instead. I have to admit I actually didn't know how to do two things regarding Java up until trying to work around this exercise:

• how to implement namespacing;
• how to make a JAR

Sad admissions indeed! Well I knew the rudimentaries of both, but had never needed to put them into practice, so didn't know the details.

Just in case you're as thick as me when it comes to Java, here's what I learned. Firstly a baseline:

class Greeter {
    public static String gday(String who){
        return "G'day " + who;
    }
}

If I compile that, I can just stick Greeter.class file into /WEB-INF/classes, and use it in my CFML, eg:

// sampleBasic.cfm

greeter = createObject("java", "Greeter");
writeOutput(greeter.gday("Zachary"));

And we get:

G'day Zachary

Next... namespacing it...

package me.adamcameron.miscellany;

class Greeter {
    public static String gday(String who){
        return "G'day " + who;
    }
}

And now this class needs to go in /WEB-INF/classes/me/adamcameron/miscellany before we can use it:

greeter = createObject("java", "me.adamcameron.miscellany.Greeter");

Note how the package needs to be expressed everywhere.

Finally, making it into a JAR instead. This uses the same code, but I needed to home Greeter.java in the correct subdirectory structure (me\adamcameron\miscellany\Greeter.java), recompile it, then run it through JAR:

C:\src\java>jar cf miscellany.jar me\adamcameron\miscellany\Greeter.class

C:\src\java>

This creates miscellany.jar, and to use that, I pop it into /WEB-INF/lib (not /WEB-INF/classes, nor /WEB-INF/lib/me/adamcameron/miscellany).

That was all pretty easy. However note that whilst the class-based solutions (both non-packaged and packaged versions) work A-OK on ColdFusion (all versions), Railo (all versions), and Lucee 4.5; they do not work on Lucee 5. On Lucee 5 the only option that works is the JAR version. This is not exactly a hardship, but it's worth knowing.

I tried to get some sort of acknowledgement of there being an issue here from Lucee, but that didn't pan out. Micha's dismissive, excuse-making, unhelpful attitude really irked me here: LDEV-315. He's basically blamed me, Tomcat, all other CFML engines (including Lucee 4.5 I guess) but not any action on his part which might have caused this regression. According to him Lucee 5 is working correctly, and all the other ones are behaving the way they do purely by coincidence (and different vendors implementing the same coincidence). At the same time, inferentially suggesting to Tomcat and Servlet docs have it wrong. He's beginning to sound like Rupesh from the Adobe ColdFusion Team in his excuse-making squirming.

I can surmise that the way the Lucee classloader has been rewritten for OSGi support either necessitates this change, or there's a glitch in it which causes it. I could not find OSGi docs making any claims one way or the other, unfortunately.

As I say on the ticket, at the very least Lucee need to document this change, but Micha - who's generally a bit averse to appropriate levels of documentation in the first place - didn't even accept that. The ticket is closed with the familar (from the Adobe bug tracker, anyhow) "Closed/Won't Fixed/Can't be arsed". This is a pity.

Anyway, at least I know about packaging and JARing in Java now. Win!

--
Adam

Railo doesn't speak

G'day:
Last week Railo contacted me and asked me to raise awareness of a new blog article they had published (their article: "A message from the majority shareholder of The Railo Company"; my initial reaction: "Railo speaks at long last"). I duly mentioned it in an article of my own, as well as a follow-up article ("Questions for Railo") asking some questions that sprang to my mind and a few others from the peanut gallery.

I was hoping Railo might've responded to these questions because their article did kinda elicit more questions than it answered. However now there's been absolute radio silence from them for a week, so this raises even more question marks.

PHP: inadvertently looking at a coupla refactoring tactics with Twig

G'day:
Here we have details of me unsuccessfully trying to replicate an issue we are having with one of our Twig files... it's not seeing some data being passed to it. However along the way I got myself a bit more up to speed with a coupla refactoring tactics one can use with Twig.

This article doesn't cover everything about Twig (I don't know everything about Twig, for one thing), it just covers the troubleshooting steps I took too try to replicate the issue I was having.

Spoiler: I did not solve the problem.
Spoiler spoiler: or did I?

This Railo v Lucee thing: a well-balanced reaction (from someone else)

G'day:
I had a response to make to a comment this evening, but Ron Stewart beat me to it, saying pretty much what I'd've said, except better. And more politely. I wasn't going to bother being polite.

'ere' 't'is.

It's in response to Dom's comment, which was a slightly befuddling reaction to my article this morning, "Questions for Railo". Dom's post seemed to take offence at the fact I delivered inconvenient information, and I have an opinion which is contrary to the zeitgeist. And that I have derided some of the less coherent reaction I've been seeing. Which is odd, cos he's read this blog before.

Anyway, I was gonna reply after work, but I've been trumped by Ron who's written what I would have said (like I said above).

@Dominic: I'm not one for putting words in Adam's mouth (seems dangerous to me) but I too was a little surprised by how some people responded either on Twitter or in the comments on the Google Groups posting in a manner that either

(a) seemed (to me) to lose sight of what I thought was the primary basis for the disagreement between 4FTI and the people behind the Lucee project: some sort of contractual agreement regarding IP rights, or

(b) automatically assumed that the entity behind the post was automatically wrong, without grounds for their position, some sort of bad guy, or out specifically to harm the Lucee project (they may be any or all of those things... or they may not be).

There's a great deal about all of this that we on the outside simply don't know at this point in time, and to automatically assume that the entity behind the post on the Railo blog has no basis for their position and/or for addressing what they perceive as a grievance or breach of contract through litigation is probably unwise. The claims made by the entity behind the blog post on the Railo site may be without merit... or they may not be. We just don't know.

As I posted on Twitter, the underlying disagreement between the two sides in this case is troubling to me (I used the word "disturbing" in my tweet) because it, at best, will likely be a distraction for continued development of the Lucee project until it is resolved. I also noted that that the cynical part of me was sort of expecting this given the protracted silence from the Railo side since the Lucee project began... given what we had publically heard about financial backing for and commitment to the long-term future of CFML through Railo, it seemed quite likely to me that the entities backing Railo would be quiet that long if they were trying to figure out what this meant for their investment and their future... maybe I was reading too much into the silence. I think we now have some idea of where they stand.

I saw some of the reaction as a surprising rush to judgment, given how little any of us know about the circumstances behind the principals leaving the Railo side, any contractual agreements they may or may not have had with the Railo side, conversations that may have occurred between the two sides since they left the Railo project as they two sides may or may not have attempted to come to some sort of agreement on points of dispute. I don't think we know enough at this point to start talking about who's right, wrong, good, bad, or anything else in this case.

Does all of this help the CFML community? Or Railo? Or Lucee? No, almost certainly not... but neither does our jumping to conclusions about "right" and "wrong" or "good" and "bad" in situations where we aren't currently--and may never be--privy to all of the relevant facts.

I think Adam is/was doing the same thing to the CFML community that he often does with the vendors: taking them to task for what he sees as questionable reasoning. I don't see his position as "pandering" or even an extreme case of playing the devil's advocate. But that's just my perspective...

I'm curious about the answers to some of the questions he's posed here (particularly the forward-looking ones), and to see how this plays out.

Questions for Railo

G'day:
Well: what a flurry of hysteria we had yesterday, eh? (if you missed it: "Railo speaks at long last", then go to the Lucee Google Group or Twitter for more reaction). I can't say I was particularly impressed with some quarters of the CFML community with their froth-based conspiracy theorisation, but I think this reflected mostly on themselves more than anyone else. I'm also surprised at the road from Palm Sunday-esque adulation to shrieks of "Crucify Them!" Railo have apparently transgressed over the last few months. We've definitely split from the Judean People's Front to create the People's Front of Judea, it seems.

Still... There's some sensible questions to be asked off the back of all this. Some of these come from me, some of them are questions others have asked which seem to have merit (at least to some degree).

Please post a comment on this article

G'day:
I'm having some issues with Disqus, perhaps linked to me changing some email addresses.

Could you pls post a comment on this article? I just wanna see how / when / to where I get the notifications.

Oh, if by the time you see this it already has a few comments... no need to bother.

Update:

Cheers, have fixed the issue now.

Cheers.

--
Adam

Railo speaks at long last

G'day:
I'm going to get this out quickly without any analysis (I've not even finished reading it!), but Railo - yeah Railo, not Lucee - have just posted this on their blog ("A message from the majority shareholder of The Railo Company"). The whole thing warrants reading and digesting, but this is they key section:

What this means for Lucee

Again, we support the spirit and intent of the Lucee initiative, although we fail to see the advantage of another CFML platform. However, the use and development of Railo to release what is now being “packaged” as Lucee 5 was not authorized by TRC and, therefore, remains the property of TRC.

For this reason, we are compelled to provide notice that any use of Railo by Lucee or by its membership may constitute an unlawful infringement of TRC’s intellectual property rights. We strongly urge you or your customers to request that Lucee and its founders warrant that nothing contained in any Lucee release is subject to claims from third parties including TRC and that all IP is free and clear to Lucee. We are confident that no such warranty can or will be provided.

All of these internal issues will take time to sort out and we will try to keep you updated throughout.

Hmmm.

My initial reaction is that one would be foolhardy to run with Lucee whilst there's clearly some issues to "iron out". It might end up just being an agreement being made with TRC to allow them to distribute Lucee. Or it might mean "Lucee" is not allowed to exist, legally. I think this is up in the air at the moment.

That said: I'm no lawyer, so what do I know.

Update:

Alex has pointed this out:

This isn’t Railo speaking this is another TRC shareholder and the article title should reflect that, [...] they are a majority shareholder [...] TRC's other shareholders don’t agree with the position being taken?

(full context is in his comment below. I have edited that down, and this expresses his intent, but not his exact wording).

My reaction to that is this:

It's the Railo blog and they're talking about Railo stuff, so that's "Railo speaks..." in my books. I'm not that fussed by who owns what shares, and realistically I think this messaging *is* the official word re Railo whether all share holders agree or not.

TBH, I'm not sure this hair-splitting is helpful or meaningful, but I've now had this conversation three times with various people, so I figured I should get my reaction front and centre.

One thing I do know... this squabbling between Railo & Lucee is not helpful to anyone in the CFML community (except perhaps Adobe). And I say that in a non-partisan way. I don't know enough to know who's the right or the wrong party in any of this.

I think the body left worst off is the CFML community though.

Update, after some thought:

These are my initial thoughts, as posted in a comment on Railo's blog article:

Very interesting news! Not entirely helpful from the perspective of the continuity of the CFML community, but interesting nevertheless.

What would be *best* is if you @ TRC and those @ LAS could swallow their egos and their differences, ditch Lucee, and go back to just doing Railo.

I'm fairly certain that won't happen though :-/

Best of luck, and I will definitely be "watching this space"!

What are your own thoughts on any of this?

--
Adam

Change of persona

G'day:
Just a note... if you have my dac.cfml GMail address on file... get rid. I'm discontinuing it.

Clarification / retraction re Lucee community participation

G'day:
I mean to post this y/day, but forgot.

Brad pointed out I've been talking porkies about Lucee's popularity / community size:

Also, you and Sean are spreading what I believe are misleading "facts" about the "fragmentation" of the community. Firstly, the total number of members is no indication of the number of active members. Any list will accumulate old accounts after a few years, but that doesn't make it more active. Adam you said there is "so little traffic on the [google group]". Let's take a look at the stats.


https://groups.google.com/forum/?hl=en#!aboutgroup/railo
https://groups.google.com/forum/?hl=en#!aboutgroup/lucee

Before the Lucee announcement, the Railo list averaged 496 posts a month on 87 topics. Since its inception, the Lucee list has averaged 1,137 posts a month on 83 topics! That's pretty much the exact same number of topics and over TWICE the posting traffic.

"M"? M!

G'day:
OK, enough fo the single letter blog titles with no bodies (ref: "M"). What was that all about? Well AndyK correctly guessed this morning:

My colleague Brian got the literal meaning,but not the implication.

M... 1000. Plus indeed the dual meaning "milestone" was in there too.

So, yeah, that was the 1000th "article" on this blog. Initially I was gonna do a "well let's reflect on that", like I did with "Bad Request" and "500: to put things in perspective", but then it occurred to me that's really a bit hubristic. In reality what I'd achieved is engaged in one of my hobbies 1000 times over the course of a coupla years (1023 days to clarify Andy's frequency estimate). This is not an achievement, it's just me passing the time doing what I like.

But it was at least worth an odd article title with no discernible content. Again.

Well done Andy... I'll get you a beer when I see you.

Andy also spared you tomorrow's article title which was gonna be "k", with a body of "10000000000". I'll have to think of something else to write now.

--
Adam