ColdFusion 8, Java, .NET

[Dinghus]

Okay, so CF8 can interact with Java and .Net but where can I find a list of the objects I can call from them? I know a few but can't find anywhere a comprehensive list. Anybody know?

[-__cfSearching__- · Accepted solution]

You probably will not find a list because it is quite extensive.  On the java side you can access any of the core java libraries. The exact list varies depending on which jvm you are using:

http://java.sun.com/javase/6/docs/api/

As well as any classes/jars that are within the CF classpath.  The classpath varies based on your installation type and environment. But it usually includes all of the jars in the installation "lib" directory:   ie c:\coldfusion8\lib\ . That directory contains the core CF jars as well as many third party libraries like iText, apache commons, etcetera. You will need to do a google search to find the documentation/api's for the individual jars. Most are pretty standard so they are not hard to find.  (A word of caution: The libraries are used by CF to provide core functionality. So moving or updating any of the core jar files could break CF)

I am not very familiar with .net side.  But a quick google search revealed the .NET framework installs the BCL library. So locally anything in the System namespace _should_ be available.
http://en.wikipedia.org/wiki/Base_Class_Library

Another reference mentioned that any assemblies present in GAC should also be accessible. This article shows how you can view the GAC
http://geekswithblogs.net/pavelka/archive/2006/05/05/WindowsExplorerAndTheGlobalAssemblyCache.aspx

HTH

[tooMuchTrouble]

pick a subject, there's tons & tons of java libs.

i18n? icu4j

super funky charting? jfreechart

GIS? mapserver mapscript, geoserver, JTS, postGIS

image processing? imagero, JAI

mythbuster science stuff? jScience

i could go on all day....

like cfsearching, i don't do much .net & can't suggest much but a little

googling should fix that.

[Dinghus]

I must be searching for the wrong things. I haven't found anything which

is why I asked here. :^\

[-__cfSearching__-]

So are you looking for something particular like Paul asked .. or are you just getting your feet wet and would like to know what might be lurking beneath the waters ? 😉

[Dinghus]

I'm getting to rebuild an application that was done in 4.5 and there are

some things from .Net and even Java that I was thinking about like true

listeners etc. But I also like to see what is out there. Someday it may

just come in handy.

[-__cfSearching__-]

Well, most things you could probably do with plain cf.  But yes, definitely look at the java/.net stuff anyway.  If only as a learning exercise.

... like true listeners etc.

Most of the standard cf frameworks have the listener concept.  So I am curious, how do they differ from a "true listener"?

[Dinghus]

From what I see in the frameworks they are just pseudo listeners. They

are actually informed of an event and then they handle it. A true

listener sits on the sidelines, so to speak, and detects an event then

just broadcasts the event to all objects (or whatevers) that are

subscribed to it. Then they all do their thing. If you have done any

work with Flash programming you would see that in action. I'm not sure

it is possible to do in CF since it is server based and generally

listeners work client side and stay client side. So basically a true

listener does not care what is subscribed, it just hears an event and

then broadcasts to them without doing anything else. Not sure if I

explained that very well. Maybe it is like a RSS feed vice a mailing

list. The RSS has no idea who is subscribed and just puts it out there

for whoever wants to grab it

whereas a mailing list actually has to keep track of who is subscribed

and send it to each one. That is what I've seen in the frameworks, the

mailing list style.

[-__cfSearching__-]

Dinghus wrote:

From what I see in the frameworks they are just pseudo listeners. They

are actually informed of an event and then they handle it. A true

listener sits on the sidelines, so to speak, and detects an event then

just broadcasts the event to all objects (or whatevers) that are

subscribed to it. Then they all do their thing.

Hmm. Ignoring the actual applications for a moment (there are server side type listeners as well), I am not sure I see the difference.  I think you could implement the general pattern the same way. In other words have an observer that intercepts and broadcasts events to whomever is subscribed. It does not have to care who or what is subscribed. It just notifies the interested object and let's that object do whatever it wants to when a particular event occurs.

[Dinghus]

I think the last example was the best one I can do. A listener only

listens really. It can then set a bit or whatever that others can see

and use. But it doesn't actively inform anything. The frameworks I've

seen, when the listener catches something it actively participates.

A very crude listener would be the switch or fuse box. An action comes

in (page request) and the listener (fuse box) directs where to go. So

the listener is making decisions based on what it "hears". A true

listener does not do that. Very much like an RSS. The data is there but

is not actively sending it anywhere.

Along with listeners of course have to be objects that monitor the

listener status and reacts accordingly. But you could have a dozen

objects actually monitoring that listener all at the same time. I think

the way to reproduce this in CF would be to use threads. There could be

a whole bunch of threads running each looking at whatever listeners

pertain to the thread. When 1 changes that thread does whatever or is

called to complete its actions. I'd have to think more about how to do

that without having runaway threads. I'm not even sure this level of

sophistication has a place in web apps. Probably the basic switch

listener is all that is required or even feasibly done.

[BKBK]

listeners

There are in fact no listener models, frameworks or architecture in the sense you describe. At least, not that I know of. What you've been talking about is event-driven.

[BKBK]

A listener only listens really. It can then set a bit or whatever that others can see and use. But it doesn't actively inform anything. The frameworks I've seen, when the listener catches something it actively participates. A very crude listener would be the switch or fuse box. An action comes in (page request) and the listener (fuse box) directs where to go. So the listener is making decisions based on what it "hears". A true listener does not do that. Very much like an RSS. The data is there but is not actively sending it anywhere.

In my opinion, listeners don't just listen, as you have described. They also respond, and should, to what they hear.

Generally, what we call listener is actually an event listener. It responds to an event by doing something, based on what it hears! Even RSS makes decisions, for example, how to display messages, based on the content. The response, that is, what the listener does in reaction to the event, is what makes  a listener a listener.  In fact, I would go as far as to say, no response, no listener.

[Dinghus]

Taking RSS further you can see that it does not decide WHO gets the

feed. That is why it is only a listener. It does not interact with other

processes other than to provide data to whoever wants it. Not the best

example because it doesn't really listen for anything other than

possibly a change in available data. Basically in a program you can have

a lot of different processes running and a listener will sit and watch

for particular events to occur, like new data. Then broadcast a general

message somehow, maybe as simple as changing a boolean value, to any

process that wants to know. The processes that need to know that

something has happened of interest will pick it up and do whatever it is

they do with that information. It does this because this way you don't

have to keep a list of other processes or objects or whatever in the

listener to be told what has happened. Instead as you build your process

you can tell it to check the listener instead.

Maybe a better analogy is a traffic light. It does not care how many

cars are there or anything about them. It is listening to an internal

clock, or a trip in the road, and changes color of lights based only on

what it is listening to. It does not transmit anything to the vehicles

but they respond as needed to the signal.

And many of the frameworks I've looked at have something called a

listener in them but it is actually an event handler. It reacts to an

event by making decisions for other processes or whatever.

[-__cfSearching__-]

Basically in a program you can have a lot of different processes running and a listener will sit and watch for particular events to occur, like new data. Then broadcast a general message somehow, maybe as simple as changing a boolean value, to any process that wants to know. 

That is an observer.

The processes that need to know that something has happened of interest will pick it up and do whatever it is they do with that information.  It does this because this way you don't have to keep a list of other processes or objects or whatever in the listener to be told what has happened.

Pick it up how? You do have to keep a list, or rather the observer does.  The observer must know who to notify when an event occurs. Otherwise, how could the interested parties know something of interest to them occured?

It does not transmit anything to the vehicles but they respond as needed to the signal.

Since objects do not have eyes, they receive a notification 😉 How else would they know the signal has changed unless they are notified? I know this is just an analogy, but it almost sounds as if they learn by osmosis.

BTW, what design pattern are you getting this from, because afaik neither java or flash operate like what you are describing.

[Dinghus]

That is an observer.

No. You are getting confused with the "observable" class I think. The observable class in Java does keep track of who has subscribed and then a call to the notifyObservers method has it send out a notification to them all.

Pick it up how? You do have to keep a list, or rather the observer does.  The observer must know who to notify when an event occurs. Otherwise, how could the interested parties know something of interest to them occured?

Let's go back to the traffic light. How do you know to stop or go? Does the traffic signal keep a list of all cars on the road and then broadcast to those in its general vicinity? No. That is not how it works. A listener also does not know who will be using the information it is presenting. It just puts up a different colored light (so to speak) based on whatever event it listens for. Just like the timer in the traffic signal could care less about any inputs or what is receiving the output. It times, changes its output, times some more. But it is not listening to any inputs.

This is actually very basic programming. Especially if you do OO programming. Each object has to be autonomous to be reusable. If I make a sorting module (how many remember having their stack of punch cards for a bubble sort?) I want it to plug into anywhere without having to worry about what is on the outside. You put it in, give it the proper input and it spits out the proper output. BUT it does not keep track of what objects need to be notified that it is done doing its sort. That is the job of the calling object. The sort is done, the calling object sees it is done and goes and gets the results.

What you are thinking of is called an event handler. An event occurs, it handles it. A listener doesn't handle the event.

Both Flash and Java DO have these capabilities. Have you ever created a listener in Flash? I can have 1 listener and then many others react to it because I assign them to that listener. The listener broadcasts but it really doesn't know to who. Like an air raid siren going off. Whatever has subscribed will be notified but the listener does not actually do it. The handling of the notification is hidden from you. Flash keeps the list of who is subscribed to what listeners and does the notifications. When you build the listener, you don't have to tell it who/what to notify. You tell it what to listen for and then it does its thing and broadcasts.

Now about eyes. Are you saying that a blind person can not cross the street? Does the walk signal send them a notification specifically? No. If it has a beeper on it then that is how the blind person knows to cross. But the traffic signal does not care if a blind person is there or not, it is still broadcasting the event.

[-__cfSearching__-]

... A listener also does not know who will be using the information it is presenting. It just puts up a different colored light (so to speak) based on whatever event it listens for. Just like the timer in the traffic signal could care less about ... what is receiving the output. ...
.... A listener doesn't handle the event.

Both Flash and Java DO have these capabilities. Have you ever created a listener in Flash? I can have 1 listener and then many others react to it because I assign them to that listener. The listener broadcasts but it really doesn't know to who. Like an air raid siren going off. Whatever has subscribed will be notified but the listener does not actually do it. The handling of the notification is hidden from you. Flash keeps the list of who is subscribed to what listeners and does the notifications. When you build the listener, you don't have to tell it who/what to notify. You tell it what to listen for and then it does its thing and broadcasts.

Either I am totally sleep deprived or what you are saying is not making sense 😉  I really think you are confusing something that dispatches notifications with a listener that handles events. Listeners register to receive notifications specifically so they _can_ handle the events.  That is how they work in java.  AFAIK the flash model is similar.

Can you point out where in the Flash documentation it states the behavior you are describing above, or any java documentation that says the same?

[BKBK]

Dinghus, I agree with a lot of what you say. But then, you punctuate it here and there with ideas that make the whole difficult to swallow.

Maybe a better analogy is a traffic light. It does not care how many cars are there or anything about them. It is listening to an internal clock, or a trip in the road, and changes color of lights based only on what it is listening to. It does not transmit anything to the vehicles

It does -- light.

Dinghus: Basically in a program you can have a lot of different processes running and a listener will sit and watch for particular events to occur, like new data. Then broadcast a general message somehow, maybe as simple as changing a boolean value, to any process that wants to know.
CFSearching: That is an observer.
Dinghus: No. You are getting confused with the "observable" class I think.

I think CFSearching is talking about the observer, as in observer pattern. This is a very general concept that goes beyond any particular class, or programming language, for that matter.

What you are thinking of is called an event handler. An event occurs, it handles it. A listener doesn't handle the event.

As CFSearching correctly said, a listener is an event handler. No event handling, then no listener.

We gather, every man, woman and child, and gaze at the top of the mountain. We await the word of God. The prophet, Moses, from our viewpoint the size of a little finger, moves hither and thither at the mountain top, disappearing and reappearing from behind the rocks.

Moses is our listener. No signal from him: no message from God. It is only when he raises the tablet of stone that we realize God has spoken.

When you build the listener, you don't have to tell it who/what to notify. You tell it what to listen for and then it does its thing and broadcasts.

Here I agree with you. The listener does notify, but doesn't have to know who to notify. I think that's how God built Moses.

[Dinghus]

Sigh. A traffic light does NOT communicate specifically with the cars or people or anything else. Not sure how much clearer I can make that. It puts up a different color light and the driver reacts to it.  The light does not dictate the actions of the vehicles. An event handler would be saying "light is red, car stop".  That would be part of the car.

The problem I see in all this discussion is that most people are too ingrained in the OO/Java "new speak". I'm coming from the machine/assembly/Fortran/Cobol/Pascal/wire it yourself background.

When I was in college waaaaaaaay back when, the first thing we did was learn to build adders on circuit boards. This was the first computer programming. They had to build the circuits to do what they wanted. So a listener was a physical device like a relay or some such that would trigger when an event had occured. It did not control anything. It did not handle any other devices. All it did was switch states in reaction to an input that wasn't even directly targeted to it.  But other devices/objects would "see" the change in state and react accordingly. Handlers.

Nowdays all the classes etc have combined listeners with handlers and therein lies the confusion you are having.  Java has the "observable" class which actually will send a message to all the subscribers so it is keeping the list. A true listener does not keep any lists and does not affect directly the main flowpath of the program.  It is autonomous.

Ooops. gotta run. More later.

[-__cfSearching__-]

BKBK wrote:

I think CFSearching is talking about the observer, as in observer pattern. This is a very general concept that goes beyond any particular class, or programming language, for that matter.

Correct. That general pattern used in much of java, and from what I understand, flash does as well.

BKBK wrote:

Dinghus, I agree with a lot of what you say. But then, you punctuate it here and there with ideas that make the whole difficult to swallow.

.. and that about sums it up.

[Dinghus]

You are correct. We are talking 2 different things. Observer and listener. So stop thinking observer and think listener. Throw all that other stuff out for now.

Listeners are all over the place outside of programming even. Going to a car, let me give you an example or 2. The main "program" of your car is to run the engine and drive train. Event handlers in your car are things like "throttle depressed ---> more fuel ---> etc"  A listener in your car would be one that says "brake pushed ---> taillight lights up" The main program is "brake pushed ---> calipers clamp down". The taillights have nothing to do with stopping the car and don't care if the car stops. Their sole purpose is to notify other vehicles that you are pushing on the brake pedal. Even if the brakes fail.

The brake lights do not keep a list of other cars in the area and send notifications to each car that you are pressing on the brake pedal. It is up to the other drivers ("controller") to do something (or not) with the information.  The drivers of other cars have "subscribed" to your brake lights and want to know when they go on. But the drivers do their own checking.

You can disconnect the lights and the brakes program would still work.

The confusion you are having is trying to reconcile what is currently out there with the basic principals.

For ColdFusion applications a listener would have to be an asynch thread that just keeps looping waiting for whatever to happen. Then it would broadcast probably by setting a session or application variable. I'm thinking application since the only real reason to use this would be if something occurs that multiple visitors currently on the site want to know about. Like maybe another person has logged onto the site. A broadcast would go out that a new person has signed on. Depending on what is happening with each of the visitors, they may or may not use the information. Everybody would know that this person logged in but maybe only 2 people care.

But I hate to use anything that loops forever. I'd rather have a true listener that is doing nothing until an event occurs that it needs to broadcast to the world.  Not sure if that is possible with CF.

[-__cfSearching__-]

Dinghus wrote:

A listener only listens really. It can then set a bit or whatever that others can see

and use. But it doesn't actively inform anything.

Yes, I am bit confused as well. That sounds like objects that would poll for another object for changes in state, rather than objects that listen for events and take action when an event occurs.  That is what I am referring to, something like the Observer pattern used in swing and even some cf frameworks (ie Mach-II, etcetera).  From what I know of Flash, it uses the Observer pattern too.  So again I am not sure how this differs.

[BKBK]

There's no better place to begin than the livedocs on integrating Java with Coldfusion and using Coldfusion to call .NET assemblies.

[Guest]

Hi Dinghus,

I'm a CF newbie but I have lot of experience with .NET.  I'm also new on this forum so please pardon any faux pas.

I wrote a tiny chunk of code that enumerates the methods available in a .NET assembly.  For example, if you wished to know what methods are found inside the System.IO.Directory, you could do this:

<cfset  objDotNet = createObject(".Net", "System.IO.Directory") >
<cfdump var = #objDotNet#>

I found a tool on the Web that will show which .NET assemblies are installed on your system.  I can't recall the URL for this free code, but if you Google

.NET Reflector 5.0

you should find it.

HTH,

JohnnyJ.

[-__cfSearching__-]

JohnnyJupiter you have perfect timing! I was just looking for something like that. Thanks.

Cheers

[Dinghus]

Looks like I have some research to do but I'm thinking most of that stuff is covered under CF anyway. Matter-of-fact I have another application I'm in charge of but not the programmer for, that they use java to connect to the db for some reason. What a mess of code for something so simple in cf.

But I'm getting some wicked ideas. If you see a mushroom cloud from Hawai'i direction it is just me playing with coldfusion.