Showing posts with label Lucee. Show all posts
Showing posts with label Lucee. Show all posts

Tuesday 12 May 2015

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.

Tuesday 5 May 2015

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.


Monday 4 May 2015

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

Friday 1 May 2015

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.

Wednesday 29 April 2015

Lucee: issue tracker has moved to Jira

G'day:
Well here's some good news - which happened to catch me out last night - Lucee have completed the switch from BitBucket to Jira for their issue tracking.

They've mentioned it on the Lucee Google Group - Issue Tracker now moved to JIRA - but not on their blog yet, so I figured I'm mention it here. The new URL is: https://luceeserver.atlassian.net/

Tuesday 28 April 2015

Lucee has a new forum expressly for discussing language features

G'day
This is potentially promising from the Lucee mob:

Lucee Language Forum

We've set up a new forum to better manage ongoing discussion about Lucee internals; hacking on the server itself, language specifications and implementation details.

http://lang.lucee.org

"Lucee Lang" is the home for discussing everything related to the implementation and design of the Lucee programming language and CFML compatibility layer. It will also be the home of the Lucee Technical Advisory Group and its deliberations.

Saturday 18 April 2015

Lucee 5 beta: a direct question about createObject()

G'day:
In an attempt to get a direct straight answer out of Micha regarding createObject() and loadComponent(), I have posed a very direct question about it on the Lucee Google Group:

Friday 17 April 2015

Lucee 5 beta: new beta 5.0.0.44

G'day:
The Lucee Team are continuing to have a pretty good release cycle with the beta updates: 5.0.0.44 has just been pushed out. There's a few things I raised in there which is pleasing. It's only quite a small release - eight issues fixed - but this is cool when the release cycle is so short.

The release notes were posted to the Lucee Google Group - "New Beta Release (5.0.0.44)" - but they're short enough for me to copy and paste here:

Lucee 5 beta: .lucee files

G'day:
I held off on this one hoping more information would come through from LAS, but I've run out of other documented features to look at, so here we are.

Lucee has added a new "language" to their engine, which is a dialect of CFML.

Thursday 16 April 2015

Lucee 5 beta: tag attributes fix

G'day:
Here's another quick one. I'm waylaid at work and have a few minutes to spare between one hold-up and the next one.

One of the most stupid things about the way CFML tags are processed is that in this tag:

<cfinvoke method="f" arg1=m arg2=n>

The tokens m and n are treated as strings. IE: the literal strings "m" and "n".

Lucee 5 beta: <cfloop> tweak

G'day:
There's another few odds 'n' sods with the Lucee 5 beta that are testable / demoable, but they're pretty trivial / small features, so I'll have to do a series of "misc" blog articles.

There's a bunch of more significant stuff I have not looked at yet because there's no beta documentation for them, so I cannot work out what to do. It's been observed that I am being unhelpful to the Lucee project for making observations like this, interestingly enough. I'm not one to get all biblical (although perhaps I should, but in a different sense), but Matthew 7:3 definitely spring to mind here. But anyway, whatever [gallic shrug].

OK, so they've added a new feature to <cfloop>, anyhow.

Wednesday 15 April 2015

Lucee 5 beta: abstract (redux)

G'day:
Right, after a bit of a false start with the abstract support in Lucee (ie: they forgot to release it in the 5.0.0.42 version, when I first tried it - "Lucee 5 beta: abstract components (abject fail now fixed)"), it's now all working (as of 5.0.0.43). So I'll revisit with an example to demonstrate its behaviour.

A while back I looked at how PHP dealt with abstraction: "Looking at PHP's OOP from a CFMLer's perspective: inheritance, static & abstract, interfaces", and I have taken that code and converted it to CFML and will use that as an example. It's interesting how close the code is between languages. CFML is a bit cleaner though.

Survey results: A quick OO terminology survey

G'day:
I didn't quite get 100 responses, but 95 is close enough (and not bad for over a weekend, during which this blog's readership is pretty dire).

To recap, the first two questions related to this code:

x = new Y()

First I asked whether you were more likely to describe x as:

  • a class
  • a component
  • an instance
  • an object
  • or something else

Second I asked the same question of Y.

The third question was to guess what a CFML function createComponent() might be for.

Monday 13 April 2015

Lucee 5 beta: the PHPification of CFML

G'day:
I continue to raise my eyebrow at some of the decisions the Lucee Team have been making regarding work they've been doing in Lucee.

Lucee 5 beta: final keyword (redux)

G'day:
Community stalwart and "OK bloke even if he is Australian" Andy Myers made an observation on Twitter this morning:

This is a good question, and one I did not think to check.

Lucee 5 beta: final components and methods

G'day:
I guess I need to go back and have a decent look at abstract components and methods at some stage, after my abortive first attempt ("Lucee 5 beta: abstract components (abject fail now fixed)"). But in the mean time, I'll look at the "opposite": final components and methods.

If one flags a component or method as final, then the intent is that that component or method cannot be extended by a sub component (or a method in same). This is a common feature in OO languages, although was never initially implemented in CFML's OO implementation. I really question the merits of adding it to CFML now, really. Beyond the idea that "well it should have been there", it's kind of only relevant for people building APIs, which doesn't often happen in CFML, and I've always found usage of final to be a pain in the arse more than anything actually useful. My position is I should be able to extend any class I like: it's not for the author of a class to pre-decide how I might end up using it.

Saturday 11 April 2015

Lucee 5 beta: createComponent()

G'day:
I'm moving away from Lucee 5's new additions to CFC implementation today, and having a look at one of the new functions they've added: createComponent(). Before clicking that link or reading on: try to guess what the function does.