BlueDragon continues to give me fits. CFEXECUTE (which I'm not sure – there is conflicting evidence – is supported on the Server edition) refuses to work correctly. No big deal, since launching a Process direct from the Runtime class is straightforward (I didn't need the IO streams, in this case). However, the waitFor() method of Process refuses to do anything except throw exceptions when called, which basically means no syncronized subprocesses. So what's the solution? Write a JSP page that does the exact same thing (except it works) and then call it with CFHTTP. Hardly elegant, but it worked well enough.
Next problem was doing some simple image manipulation with the ImageIO class (from javax.imageio). Nothing complex, just a simple read-scale-write operation to generate a thumbnail. However, BD pukes on the write part. From the stack trace on the NPE, it appeared that it was having trouble selecting which of the method versions (write is overloaded) to call, even though it was pretty clear cut (the one with a RenderedImage, a String, and a File). What's the solution for this case? You guessed it. Write a JSP page that does the exact same thing (except it works), and then call it with CFHTTP. Ooof.
I do tire of such hacks, and so once again, my pursuit of the CF license is in full swing. I just finished up some more work for Fusium (awaiting the check), and lined up another little project that should just about round out the two grand I need. Now if only I could be done and have the license today….
wouldn't it be easier/cleaner to just write a pojo wrapper class that BD can call? I do that all the time, even w/ CFMX (which I've seen have the same issues with certain java method signatures).
-Dave
If the web site wasn't running a hybrid of CF and JSP, then absolutely. However, using JSPs is nice because they are automatically recompiled as needed. If/When I finally go pure-CF, I'll roll it up in a POJO, unless I get CFMX, in which case I'll just put it in a CFC and retain my auto-recompile benefit.
what about spike's url class loader method? Does that work w/ BD?
Dunno. I wrote one a while back (need to start googling first, writing second) but only ever tested on CFMX. One of these days I'll rebuild it all correctly.
Hey Barney,
The JSP thing seems to be working nicely, but if you want to do it straight from CFML I have a few other possible solutions.
Does Blue Dragon have anything like JavaCast() on CF? JavaCast() has helped me get around problems of this nature in the past.
Also, have you tried creating Java equivalent objects for the parameters? i.e., instead of
<cfset stringVar = "hello">
use
<cfset stringVar = CreateObject("java", "java.lang.String").init("hello")>
Obviously, this is a simple example, but could apply to any data/object type. This should also help with the method binding, since the object references in memory should point to first-class Java objects instead of DB having to try to guess.
And if that fails… you can also use reflection to grab the method you really want, and pass it the arguments in an object array. I had to do that once to get around the dynamic proxy that CF creates whenever you instantiate a Java object from CF and then try to use it outside of CF. That also works nicely, and then you know exactly which method you're calling.
Thanks,
- max
Max,
There is a javaCast on BD, but just like on CFMX, it's only for primitive types, not for Objects. The java objects in question are explicitly created using createObject, so that's not the problem either.
I didn't think of using reflection to do the work BD is supposed to be doing for me, but that's a good idea. As it stands, doing the CFHTTP to a JSP page isn't much of a burden, and a lot simpler than dealing with the reflection stuff. It looks like I'm going to get my CFMX license in the near future, so I won't have to worry about it, since I've tested the code on there and it works fine.
Barney,
It seems like you've been vacillating quite a bit between BD and CF, with price being the stickler for not just dropping BD. Is the only reason you're attempting to get BD to work, price?
Calvin, that's exactly the reason. I can't (yet) afford the two grand for CFMX and subscription, so I use BD. For a while there (after switching from 6.1 to 6.2 beta), things were going pretty smooth, but more issues kept coming up. If cost didn't stand in the way, I'd switch to CFMX in a heartbeat. Well, more like 30 minutes, because I'd have to install and configure it, but there would be no hesitation.
I'd originally started using BD because I didn't like writing everything with JSP, and wanted to get back to CFML. JSP is more cumbersome, and slower, mostly because I'm not nearly as familiar with JSP development as I am with CFML. Though with the amount of time lost to decyphering problems with BD and then creating workarounds, I'm not sure I've been much more efficient. However, if/when I get CFMX, then I'll be able to reap the rewards of using CFML.
I'm with you on the CFML. I took a long, hard look at JSP development as an alternative. While the JSTL is great, it's still not as rich or easy to use as CF.
When I'm using CF, I feel like I'm having my cake and eating it too. CF has such wonderful Java integration (present method selection problems aside :) ) that you can get the best of both worlds – all the APIs and libraries for Java, plus the ease and power of CF's simplicity and rich function API (without even needing to install any Apache libraries).
- max
I noticed that cfexecute runs fine with BD 6.1, but with 6.2beta i try to use it to execute the same batch file as i did with 6.1 but it does not work. is this what you have experienced too? i've been trying every permission setting i can think of without luck…and am curious to know if others have seen the same problem.
thanks,
mark
Vince (from New Atlanta) confirmed that there is a bug in the 6.2 beta that prevents CFEXECUTE from working properly. He said it's fixed in the development tree, and will be functioning properly in the next release (either beta2 or RC1).