JRuby, LWJGL & OpenGL - Getting Started with Shaders

In Part 2 we drew a triangle using a Vertex Buffer, and some basic shaders. While on the surface this can seem overtly complicated, it actually becomes the basis of a powerful OpenGL achitecture to enable you to leverage the GPU is a variety of very interesting ways without having to rely on the CPU.

We'll be look at the example show_triangle_vert_frag_offset.rb, which can be run from the command bin/triangle_vert_frag_offset.

This also comes from the "OpenGL's Moving Triangle" section of the Learning Modern 3D Graphics Programming online book.

With this code, we are going to take our original triangle, and we will make it move around a bit, and also change colour at the same time.

The clever thing about this is, we won't be changing the vertex data stored in the buffer, but will instead be manipulating it with Fragment and Vertex shaders. This almost feels like Uber-CSS over the top of HTML.

This is pretty powerful stuff, as we can let the GPU do a lot of the processing by using shader programs, and passing them attributes to control the overall affect that we want.

Let's look at our vertex shader offset_vertex.glsl

#version 330

layout(location = 0) in vec4 position;
uniform vec2 offset;

void main()
{
    vec4 totalOffset = vec4(offset.x, offset.y, 0.0, 0.0);
    gl_Position = position + totalOffset;
}

You can see we now have a uniform vec2 offset;. This defines a value that is going to get passed in from outside the Shader. It has the keyword uniform as the value stays the same on the same rendering frame.

The offset attribute will be expecting a vector with an x and y coordinate to be passed through (vec2) for the uniform value.

We convert the offset vec2 to a vec4, as you can't add a vec2 to a vec4. Then we can add these two together (GLSL will do vector arithmatic for you out of the box) to get our final gl_Position vector.

This means we can change the position of our triangle with relative ease, just by changing the offset of each of the vertices.

To do this from our JRuby code, is quite straight forward. The first thing we need to do is find out the location / position of the offset attribute. This is done through:

@offset_location = GL20.gl_get_uniform_location(@program_id, "offset")

Now we have the capability to change this value as we need to. In our display function, we have:

x_offset, y_offset = compute_position_offsets(time)

compute_position_offsets calculates x and y offsets based on the current time. (Check out the code for more details, it's just some fun trig). To set the uniform value, we then do:

GL20.gl_uniform2f(@offset_location, x_offset, y_offset)

That's it. The shader then does the rest of the work. Our triangle will now go round and round in a circle.

We do similar things to change the colour of the triangle as it goes around in a circle. Here is our fragment shader:

#version 330
out vec4 outputColor;
uniform float fragLoopDuration;
uniform float time;

const vec4 firstColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
const vec4 secondColor = vec4(0.0f, 1.0f, 0.0f, 1.0f);

void main()
{
    float currTime = mod(time, fragLoopDuration);
    float currLerp = currTime / fragLoopDuration;   
    outputColor = mix(firstColor, secondColor, currLerp);
}

You can see we can define constants with the const keyword. This sets up two colours to mix between, in this case, white and green.

We have two uniform attributes to in this time, fragLoopDuration the loop duration of the colour change, and time, how many seconds have passed since the application began.

mix is a GLSL function that blends two colours together based on the third float that is passed through, and gives us the slow fade between the two as the time value changes.

Setting this up is almost exactly the same as before. We will set the fragLoopDuration in our init_program method, as it never changes across the execution of our code.

frag_loop_location = GL20.gl_get_uniform_location(@program_id, "fragLoopDuration")
@frag_loop = 50.0
GL20.gl_uniform1f(frag_loop_location, @frag_loop)


For the time uniform attribute, we have some code that tracks how much time passes between frames and we just add it all up, and then set the uniform attribute with gl_uniform like usual:

current_time = Sys.get_time
@elapsed_time += (current_time - @last_time)
@last_time = current_time
time = @elapsed_time / 1000.0

GL20.gl_uniform1f(@time_location, time)

That's the basics of using shaders with vertex data. We now have a triangle that goes around in a circle!

JRuby, LWJGL & OpenGL - Drawing a Triangle

In Part 1 we created a window, nothing too fancy. Now we get to actually display a triangle.

Just to follow along as well, I'm moving through the Learning Modern 3D Graphics Programming online book to learn OpenGL (again), so the OpenGL examples I will be displaying will be ports from the code that that is providing. I would suggest for the complete theory behind this code, read the linked section before going through the JRuby code. I expect my explanations to only be commentary on the information already provided in that series and discussion on some of the finer points on JRuby and Java library integration as well.

If you have any questions, please feel free to ask, but be aware, I'm very new to OpenGL, so writing this series is very much part of my learning experience. However, I will attempt to answer the best way I can. On the other hand, if you find anything wrong with what I'm written, please point it out so it can be corrected.

This example is from Hello, Triangle!.

The full code can be seen on Github here.

To run this example use bin/triangle

Making Vertex Data Available to OpenGL

When I first did OpenGL back in University, we used the glBegin() and glEnd() paradigm. This was definitely far easier that the more modern APIs, as it was very clear and easy to draw a simple polygon on the screen (example). However, it did mean more computation was occurring on the CPU and a larger use of the system RAM than the newer APIs. The newer APIs, while (far?) more complicated, shift much of the work to the GPU and also provide a far more flexible implementation. I liken it to working with HTML and tables back in early HTML days. Sure it worked, but CSS and semantic markup gives a clear separation and creates far more flexible implementation options (at least in theory ;) ).

So we have some basic vertex information to display a right angle triangle:

@vertex_positions = [
    0.75, 0.75, 0.0, 1.0,
    0.75, -0.75, 0.0, 1.0,
    -0.75, -0.75, 0.0, 1.0,
]

Each line of this array define the x, y and z coordinates of our triangle. You will notice there is a fourth coordinate (1.0) on each line. This defines the clip space. For now we'll just say this just means that the vertexes you see in the window has to have values between -1 and 1 on the x, y and z axis. More than that will render outside of the window.

As discussed previously, in old school OpenGL you would just look through this list of vertexes and say draw a triangle here, however, this is no longer the case!

I feel like modern OpenGL is almost like a database - you put some data into it, and have an id to reference that data that was placed in. Then you can work on that data that is stored on the GPU through some other techniques (that we will look at in a minute) via that id. This seems to be a concept that is used across the board.

The code that inserts our vertex data into the GPU can be seen in the method init_vertex_buffers

@buffer_id = GL15.gl_gen_buffers
GL15.gl_bind_buffer(GL15::GL_ARRAY_BUFFER, @buffer_id)

So first thing we do, is we generate an id for the vertex buffer, which is where we will store our vertex data. (gl_gen_buffers). Then we tell OpenGL, hey, this is the buffer we want to work with for the moment through gl_bind_buffer, passing in the specific @buffer_id we generated before. We also tell OpenGL that the buffer we are working with an GL_ARRAY_BUFFER, so it knows what data to expect.

In case you aren't aware, JRuby will convert Java static constants to Ruby constants, so we can access these static fields very easily.

To pass the vertex data into the new vertex array buffer, LWJGL has us use it's BufferUtils class to create a NIO buffer, and push the data into it, like so:

float_buffer = BufferUtils.create_float_buffer(@vertex_positions.size)
float_buffer.put(@vertex_positions.to_java(:float))
#MUST FLIP THE BUFFER! THIS PUTS IT BACK TO THE BEGINNING!
float_buffer.flip

A couple of interesting notes:

1. You will noticed the .to_java(:float). That is the JRuby code for converting a Ruby array to a Java array. Passing in :float tells it to make it an array of primitive floats.
2. The .flip at the end. This is very important (and took me a day to work out, as I'm not familiar with NIO buffers). Here is a great article that explains it more detail, but essentially the buffer tracks where it is at, and flip sends it back to the beginning. Without this, no data goes to our Vertex Array, and nothing happens!

GL15.gl_buffer_data(GL15::GL_ARRAY_BUFFER, float_buffer, GL15::GL_STATIC_DRAW)

This then pushes our vertex data to the bound vertex buffer.

#cleanupGL15.gl_bind_buffer(GL15::GL_ARRAY_BUFFER, 0)

After we are done, we tell OpenGL not to be bound to any array buffers (0 works like NULL in OpenGL land). This could be considered optional, but ensures that weird things don't occur.

Now all we have to do is actually write the code that makes the data that displays the triangle!

Telling OpenGL how to Render the Vertexes

So now we have the vertex data stored on the GPU, we have to tell it how to render it, and to do that, we have to build a program of a couple of different types of shaders. Think of Shaders kind of like the CSS of HTML. They simply work on the existing data in the GPU and tell it how it to render (although that's a bit of an over simplification).

First thing, we'll write a simple vertex shader in GLSL, the language for writing shaders. This specifies to the GPU where the vertexes actually are from the data you entered earlier. We'll just say that it's correct and basically pass it through.

#version 330
layout(location = 0) in vec4 position;
void main()
{
    gl_Position = position;
}

Then we write a fragment shader to it what colours to make things. We'll just make everything white for convenience.

#version 330
out vec4 outputColor;
void main()
{
    outputColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);
}

To make life easier for myself, I wrote a quick little create_shader function, that loads the shader from a file loads it into memory and compiles it. I just want to make note of one line:

puts file_name, GL20.gl_get_shader_info_log(shader_id, 200)

Without this, you have no idea why your shader fails (if it does). Mine was failing, and I didn't realise it until I looked deeper. (Version 330 of GLSL wasn't supported on my Ultrabook on Linux with Mesa. I had to switch to my main laptop with the Nvidia graphics card)

Make sure to look at the output logs!

Creating the program to define how our data is output on the screen, is quite similar to what we did before. We generate an id and then link the shaders to the program like so:

vertex_shader = create_shader(GL20::GL_VERTEX_SHADER, 'basic_vertex.glsl')
frag_shader = create_shader(GL20::GL_FRAGMENT_SHADER, 'basic_fragment.glsl')

@program_id = GL20.gl_create_program

GL20.gl_attach_shader(@program_id, vertex_shader)
GL20.gl_attach_shader(@program_id, frag_shader)
GL20.gl_link_program(@program_id)
GL20.gl_validate_program(@program_id)

puts "Validate Program", GL20.gl_get_program_info_log(@program_id, 200)


A few things to note:

1. create_shader returns the id of the shader. Much like a database, you reference everything you are creating using OpenGL by the generated ID.
2. We attach the shaders to the program by the id we have for that program.
3. gl_link_program essentially turns the program we're creating and makes it able to executedon the GPU.
4. We also get the program info log with gl_get_program_info_log much like we did with the shader. Make sure to check those logs!

Finally, we can get to our display loop, which you can see in the display method.

#set the colour to clear.
GL11.gl_clear_color(0.0, 0.0, 0.0, 0.0)

We clear the page with a nice transparent colour.

GL11.gl_clear(GL11::GL_COLOR_BUFFER_BIT)

This clears the screen, so we can redraw with impunity.

GL20.gl_use_program(@program_id)

Tell it to use our shaders

GL15.gl_bind_buffer(GL15::GL_ARRAY_BUFFER, @buffer_id)

This tells it to use our vertex buffer

GL20.gl_enable_vertex_attrib_array(0)

Tells it to pass each value of the vertex buffer to the first argument of our vertex shader.

GL20.gl_vertex_attrib_pointer(0, 4, GL11::GL_FLOAT, false, 0, 0)

This tells OpenGL how the structure of the vertex buffer data matches is structured. Here we are saying that we have an array of floats, and every 3 elements is a x, y and then z member, with the fourth defining the clip space, as we saw earlier. (0 is the start, 4 is the size).

GL11.gl_draw_arrays(GL11::GL_TRIANGLES, 0, 3)

DRAW THE TRIANGLE! 0 is the start of the array of vertices you want to draw, and 3 is the number of indexes you want to process - in this case 3 to make a triangle.

GL20.gl_disable_vertex_attrib_array(0)GL20.gl_use_program(0)

Finally we use the magic OpenGL 0 to clean things up again, and we are done!

We now have this amazing triangle.

Writing a Game: Feels like I'm Going Around in Circles...

Warning: This is going to be far less technical, and more about the journey of learning that I'm enjoying.

As per my previous blog post, and from several tweets I've posted, I've been slowly plodding away on doing some game development in my spare time and in my holiday break. I originally started doing this because I've always loved games, and was deeply inspired by the indie game development scene and some of the incredible ideas that were coming out of that.

That also being said, I was really keen to try a new programming challenge. Something totally outside of my usual purview, and doing game programming seemed like a perfect fit for that, as it sat so far outside my usual environment of building web based business applications. What I didn't realise was how much it was going to push me in both directions that we new and also topics that I've learnt (far?) in the past and unfortunately forgotten much about.

One aspect that has totally blown me away was the architectural idea of "Entity Systems" (ES) for game development. (I'm not going to explain it here, there are way too many good articles on this, but if you want to read more click the link above). For what is such a relatively new idea in software development (< 10 years old if what I believe is correct), it fits so incredibly perfectly into how to write some insanely flexible game architectures, I have been rolling it around inside my head for other ideas of where it can be applied.

Since the last blog post, I refactored my entire code base into an ES architecture, and that was a fair bit of a mental shift away from a traditional OO model, but the more I use it, the more it just makes an incredible amount of sense. From the screen shot below you can also see I started adding some graphics to the page too, to make a little nicer to look at.

Some of the basics (and beginnings) for this came from the awesome SpriteLib project, but I also decided to start doing some drawing and try my hand at doing some of my own pixel art. Most people probably don't know this, but I used to draw a lot. I even spent a year in design school... but to be honest, I was nothing special at it and ended finding a real passion for programming. But doing this game programming stuff has got me sketching out little characters and whatnot again, so it's been a real pleasure to rediscover this passion for drawing that I haven't touched in probably over a decade.

My next step in the game is to do some basic physics, nothing too special, just a player and some jumping to move around the world. Suddenly I'm back in high school doing kinematics and dynamics! I've still got all my old maths and physics notes from high school, so I'm pouring over that and also reading some great websites as well, and the concepts and equations are slowly coming back to me.

While doing that though, I started to look at the development cycle of Slick2d and the fact that it seemed like many people (including the original developers themselves) where moving over to libGDX. Comparing Slick2D and libGDX, you can clearly see that Slick2d has a far lower barrier to entry that libGDX. From my review of libGDX, having some knowledge of OpenGL and how 3D graphics work (even on a 2D project) is going to be a huge boon. So now I'm wondering - do I switch to libGDX? It looks more active, performant and gives far more options for distribution (desktop, web, android).

Again, I'm back to looking at old code from University - specifically my 3D programming class, and trying to make heads and tails of the OpenGL code I had previously written (in C++ no less). It vaguely makes sense, but there are concepts there I have either partially or totally forgotten (what is a Quad again? And different projection modes? no idea). Therefore, I'm going to keep playing with OpenGL some more, just to get that basic foundation under my feet, starting with the very low level lwjgl project with JRuby, and just keep going forward one step at a time, and then probably refactor my code again into libGDX once I'm done. While I don't think I have to really know OpenGL to use libGDX, I always feel more confident having the base understanding under my feet. That and I think it's a direct path to re-learning concept as vectors and 3d math with matrices that really is core to any sort of advanced game programming (yeah, forgot most of that too).

So overall, it feels like I am going around in circles a bit - but not in a bad way. I'm finding old things that I used to love doing (drawing and math) and rediscovering the joy I had in doing them, and although it's frustrating knowing that you have forgotten the knowledge you wish you still knew, it's a delight to reopen these memories and play with them once again.

Procedural Land Creation with JRuby, Slick2D and Perlin Noise

For something different, I decided I would try my hand at doing some game development programming. I was incredibly inspired by many of the indie games I watch being actively developed, and I figured it would be a interesting way to learn some brand new things totally outside of my usual purview.

I wanted to do some more work with JRuby, as I had a good hack with it at work, but haven't touched it in a while, so I hunted down which framework for doing a game. I've decided I wanted to do a desktop based 2D something (no idea what still), so settled on Slick2D as my framework of choice.

I've starting leaning towards doing something open world-ish, which meant I needed to generate out a large chunk of landscape without having to hand build a map, and yet also make sure it was the same every time a user came back to a particular world. That lead me to start investigating Perlin Noise, and I settled on the perlin_noise ruby library for generating that, and so far it's been very good.

It's been interesting too, having JRuby as the platform. It's a tough choice deciding whether to use a Java library or a Ruby one. With Slick2D it was easy - it was the best there was, and it hooks straight into OpenGL. With something like a Perlin Noise library, ease of use was the primary concern, and managing gems with Bundler and having a direct line to a nice Ruby syntax based API was the deal clincher. Although if it ever becomes a performance concern, I may look to go back to straight Java.

So here is a video of what I have so far. It's still very raw, but basically it's a circular big world, that if you go one way for long enough, you come back right where you started.

I'm extending Slick2D's Shape class to create my world object (basically a circle that I modify with my generated perlin noise). I've already set it up so the world has a "coordinate", and that controls what the world looks like. In theory, if this ever becomes a real game, you could give someone else your world coordinates and they would see the same world you do.

Before anyone asks, I've not decided what this is going to be, or if I'll open source it, or what (it's a bit of a sandpit at the moment), but I'll keep writing a diary here of what I've been doing with it, with appropriate links as long as it keeps staying interesting.

Got a few ideas on where to go next (zoom in and out, dynamic texturing of the landscape, etc), but haven't committed yet. This stuff is pretty interesting, and very different from the sort of stuff I code on a day to day basis.

Let me know if you find this interesting, and I'll keep writing about it!

Simplify Threaded Processing with FutureThreadedWorker

Having worked with both Groovy, (J)Ruby and, Java and (to a much smaller degree) Clojure, I can pretty easily claim that ColdFusion's threading and distributed processing capabilities.. leave a little to be desired. (Okay, actually a whole lot).

There are solutions though - using a job queuing system like Amazon SQS, IronMQ, or if you are looking for a something more threaded, dig into Marc Esher's awesome cfconcurrent project.

But sometimes you just want to take an array of values and run them through some sort of processing in a threaded manner, without having to jump onto any other projects or infrastructures, and without having to write that nasty <cfthread> create and join pattern for the millionth time.

So I wrote a quick CFC I've called 'FutureThreadedWorker', which does exactly that, without half the code you would otherwise need. (Note: this was written for ColdFusion 9. It would be a bit nicer if I could use closures)

<cfscript>
   //create, passing in an array for the array of structures (which are the arguments passed to the workerMethod)
   //then pass it the worker to call the worker method on
   //tell it how many thread it's should use
   //finally, tell it the name of the method to invoke.
   var future = new services.util.FutureThreadedWorker(queue, this, 5, "doWork");

   //start the running
   future.run();

   //if I want the results, wait for them.
   var results = future.get();

   //if i want to check for errors
   var errors = resuls.getErrors();
</cfscript>

Bam. That's it.  The FutureThreadedWorker now loops around the passed in array, and passed in the arguments to the method specified on the worker without you having to worry about creating threads or joining them back up again. I think you'll find that a lot easier than using <cfthread>.

JavaLoader 1.1, and a Move to GitHub

A couple of new items in this release of JavaLoader:

• A few bug fixes in the NetworkClassLoader that allowed the Tika library to work.
• A new function for switching out the ThreadContextClassLoader.

The new function, swithThreadContextClassLoader() is useful as it is often required when dealing with libraries, such as dom4j, that use the ClassLoader to define singletons or search for implementing classes, and don't allow you to overwrite what ClassLoader they use. Check out the wiki for more details on why this is neccessary, and how easy it is to now do, thanks to our new function!

Also, JavaLoader has been move to GitHub, along with the all the documentation. This should make collaboration much easier moving forward!

Otherwise, make sure to sign up to the mailing list, and enjoy loading your Java.

Dzone RefCard - Leveraging ColdFusion 9 Exposed Services from Java

Presenting and Teaching at cf.Objective() 2010

JavaLoader 1.0 Beta 2 Released

• Performance improvements in loading classes
• Fix syntax so that JavaLoader 1.0 can be loaded on ColdFusion 7
• Extend the documentation

My Interview on Dzone - ColdFusion and Java Integration

The interview I did with Dzone at the Adobe MAX conference is now online!

In the interview we talk about a variety of topics, mainly centred about how and why to integrate ColdFusion and Java together, but also touching on things like Object Relational Mappers, including ColdFusion 9's integration with Hibernate.

Hope you like it, and please give it a nice 'up' on Dzone.

JavaLoader 1.0 Beta Released

JavaLoader 1.0 is moving from Alpha to Beta with only a few small bug fixes and enhancements.

If you are not familiar with JavaLoader 1.0's functionality, you can have a look at my previous blog post , the documentation and/or the presentation I did at MAX for more information.

The was a logic bug in the way that dynamic compilation was occuring across multiple source directories that has now been resolved, and should also ensure that compilation is much faster than it was in the Alpha.

The other enhancement was to allow for relative paths in the Spring integration.  To explain, in the Alpha, you would often end up having to input your beans similar to this:

<coldfusion:cfc id="message"
        script-source="file://${root.path}/model/Message.cfc"
        script-interfaces="com.IMessage"
        />

Which can be a bit of a pain, as injecting a dynamic value for ${root.path} is not as easy in Spring as it is in ColdSpring.

Now, by default, 'script-source' attributes are relative to the calling page, so you can do your bean definitions like this:

<coldfusion:cfc id="message"
        script-source="file:///model/Message.cfc"
        script-interfaces="com.IMessage"
        />

and the path will be worked out for /model/Message.cfc relative to your application path.

Oh, and don't forget - if you are into integrating Java and ColdFusion development, make sure you sign up for the Google Group !

JavaLoader 1.0 Beta can be downloaded here .

MAX Presentation Recording: ColdFusion for Java Developers

Talking Java and ColdFusion Integration on CFPanel this week!

JavaLoader 1.0 Alpha is Released!

Dynamic Compilation

ColdFusion Component Dynamic Proxy

Spring Integration

Read More

ColdFusion 9 ORM - Explaining Hibernate Object State

In the previous two articles, we started the discussion of Hibernate Sessions and how they related to the ColdFusion 9 ORM.  We noted the fact that a Hibernate Session keeps track of what objects it loads, and can therefore update it when it realises that the object has changed.  The question then posses itself - if a Hibernate Session has closed, which happens at the end of every ColdFusion request, what happens to the objects that it was managing?

Going forward, I'm going to reuse the Musician model I used in the Introducing ORM in Adobe ColdFusion 9 beta Adobe DevNet article, for which the updated code samples can be found here.

The very short version for those who don't wish to look at the code, is a model in which we have a Musician, who has a name, and an age, and he/she also has a many-to-many relationship to an array of Instruments, which they can play.

As far as Hibernate is concerned, there are three different states for any Object that it interacts with.

Transient

Since john is never saved, it will always be transient.

Persistent

Since larry was retrieved from the database, he is also persistent.

Detached

• If the object being passed in is transient, INSERT it to the database.
• If the object is already persistent in the current Hibernate Session, do nothing.
• If there is already an object that represents the same Entity data persistent in the Session, throw an exception
  
• Otherwise, update the database with the information in the passed in object, and set its state to persistent.
  

Speaking at MAX this year - ColdFusion for Java Devlopers

Ever since ColdFusion was re-implemented as a J2EE application, the benefits of combining Java and ColdFusion application development have been easy to see, and widely used across the ColdFusion landscape.

This talk will look at some of the ways we can already take advantage of common Java libraries in ColdFusion, and enable Java developers to leverage the libraries and frameworks that they are already using. We will also be looking at how Java developers can seamlessly leverage the dynamic scripting language of ColdFusion, within their Java code, to easily enable them to take advantage of some of the RAD features that come bundled with ColdFusion.

ColdFusion 9 ORM - Explaining Hibernate Sessions

Now that ColdFusion 9 is in public beta, I wanted to write some articles explaining how Hibernate is actually working under the hood of the nice ORM integration we now have.  Like all powerful tools, they can do a great many things - but only if you really understand how they work.  Otherwise, they are potential for disaster if you don't know what you are doing.

Hibernate Sessions

1. opening a Session, i.e. we tell Hibernate 'Hi', which starts our conversation.
2. Tell Hibernate to retrieve our Caveman fred, through our session.
   
3. We change the age of fred to 32.
   
4. We close our session, and say 'GoodBye' to Hibernate for now.

Hibernate Sessions and Web Applications

You are actually able to flush the Session, which forces it to persist any changes to the database right then and there, and not wait until the end of the request, which can sometimes be very useful. 
To do this in Java, you could go:

session.flush();

But in ColdFusion you write:

ORMFlush();

UPDATE: You can read more about Session Flushing here, which outlines that there are times in which Hibernate will flush a Session in the middle of Session, however, there is often no guarantee except in specific circumstances.

It's also interesting to note you have direct access to the Hibernate Session if you so desire through ORMGetSession(), which gives you access to that request's Hibernate Session object, so you can interact with it directly.

There is much more to Hibernate Sessions and how they relate to the objects that they manage, but this will give us a good start to build upon for now.

You can read more about ColdFusion and Hibernate Sessions in the documentation Hibernate Session Management.

ColdSpring News, CFConversations RoundTable and other cf.Objective() tidbits

Conduit: The ColdFusion Adapter for BlazeDS

<adapter-definition id="conduit" class="com.compoundtheory.conduit.adapters.ColdFusionAdapter"/>