issue with CFCDynamicProxy

[Dirk Eismann]

Hi Mark,

I tried to use CFCDynamicProxy to call a CFC from inside a Java class.
This works fine as long as the Java class is invoked from CF (using
javaloader's create or CFs createObject() method).

However, if the Java class is invoked without any CF context (i.e.
from a pure Java Servlet or JSP page in the same CF webapp),
CFCDynamicProxy throws a null pointer exception from the invoke()
method.

I tracked it down and the reason for this is, that there's no
FusionContext and the call to FusionContext.getCurrent().pageContext
raises the null pointer exception.

The workaround I found is to create a new FusionContext (I misused the
CFCProxy class that comes with CF) before calling the CFCDynamicProxy.

So a nice addition to CFCDynamicProxy would be a check for a current
FusionContext and the creation of a new one if none exists.

Dirk.

[Mark Mandel]

Dirk,

You are completely correct about the context.

Out of curiosity, what is your use case for this?

I'm just curious, as I've not seen anyone really use CF outside of a ColdFusion context, and I know it can be a pain to setup CF inside a JEE app.

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

[Dirk Eismann]

Hi Mark,

the application is a real CF application running on the integrated
JRun currently. onApplicationStart we setup a Spring
ApplicationContext by using your Spring support for javaloader. The
Spring context itself loads up JPA and a lot of other stuff, so the
whole persistence layer is done in pure Java running inside a CF
application.

The application also uses a Flex/AIR client as the frontend that
communicates with the backend by using Remoting / AMF. However, we do
not invoke a CFC as the service layer here but again a pure Java class
as 80% of the work we do there is again pure Java. The remaining 20%
ist stuff we use CF for, mainly PDF-forms related stuff and some
CFIMAP and CFMAIL stuff - we do this because it's so much easier in
CF. Some of the methods in the Java Servicelayer therefore need to
call methods implemented in CF. So we inject use CFCDynamicProxy in
the Spring context and inject these into the Servicelayer bean.

Finally, when a AMF request comes in the Servicelayer may need to
delegate the request to a CFC instead of a Java class. As the HTTP
request is not hitting anything related to CF at this point there's no
FusionContext the moment the CFC is invoked. Currently, we just setup
a FusionContext in the moment before we call the proxied CFC (which
works).

Honestly, I'd never thought I would need such a setup but it really
works great :)

Dirk.

[Mark Mandel]

Now I'm just asking because I am curious ;o)

I'll dig into how the ColdFusion CFCProxy does it, and implement something similar for the DynamicCFCProxy if the current FusionContext is null. (I guess I will have to load it in a JSP for it to be tested.. this will be interesting).

So are you loading up Spring inside JavaLoader? or are the JavaLoader tools loaded with CF in the classpath (i.e. placed in the /lib folder)?

I only ask because if you are using JL, I'm wondering how you are exposing the Spring Remoting to your Flex/AIR application.

Fascinating stuff!

Mark

[Dirk Eismann]

Hey,

> I'll dig into how the ColdFusion CFCProxy does it, and implement something
> similar for the DynamicCFCProxy if the current FusionContext is null. (I
> guess I will have to load it in a JSP for it to be tested.. this will be
> interesting).

cool - currently I use AOP to startup the FusionContext just in
time :)

> So are you loading up Spring inside JavaLoader? or are the JavaLoader tools
> loaded with CF in the classpath (i.e. placed in the /lib folder)?

it works like this:

1) in Application.cfc onApplicationStart() Javaloader is used to load
spring,jar, your spring support jars, some hibernate jars, jpa stuff
and some more libraries plus a classes folder with compiled classes
for the app (mainly JPA annotated entity classes mapped with
Hibernate)

2) Javaloader creates a new Spring context similar to your example
from the docs and loads the applicationContext.xml file

3) Spring initializes the beans (Java beans and CFC proxies)

4) using a custom FlexFactory (implemented as a Spring bean) I create
a new RemotingDestination on the MessageBroker living in CF and inject
a ServiceFacade bean

5) ServiceFacade bean acts as the remote Service that gets invoked
from Flex/AIR

6) when a remoting request comes in, the ServiceFacade invokes
business logic on injected Spring beans (either Java beans or CFC
proxy beans)

I first thought I'd just use a CFC for remoting as usual, but this has
some issues when it comes to serializing Java objects to AMF and vice
versa. Therefore I switched to a pure Java remoting endpoint which
calls CFCs instead of having a CFC that calls Java :)

I also thought about using the Spring BlazeDS Integration stuff (which
I used in BlazeDS before) but my custom solution works just fine here.

Dirk.

[Dirk Eismann]

Hi Mark,

another useful thing would be if the getCFC() method on the
CFCDynamicProxy was public.

Currently, I need to get the original fully qualified "classname" of
the CFC in dot natation which could be done by querying metadata of
the CFC / TemplateProxy. Currently, getCFC is private to the
CFCDynamicProxy.

Dirk.

[Mark Mandel]

The only issue here, is that you wouldn't be able to call it... as the CFCDynamicProxy is a dynamicProxy. CF/Java has no idea it is a proxy, so if you try and call the method it would fail.

What I think you really want is a static method on CFCDynamicProxy that tracks proxies and their CFCs, and can give you them back. Something like getOrginalCFC(Object object) : TemplateProxy.

Mark

[Mark Mandel]

For future reference as well, there is a issue tracker on riaforge:
http://javaloader.riaforge.org/index.cfm?event=page.issues

I'll enter these 2 enhancements on there as enh, and we can track them on there.

Mark

[Mark Mandel]

Hey Dirk,

I've been thinking about how to automate the creation of the FusionContext.

The annoying this is going to be working out what the Application name is (which may not be a problem for you in your given context).

Would you mind sharing with us how you are setting up the FusionContext?

Is it just case of:

FusionContext.setCurrent(new FusionContext());

And being done with it?

Mark