Using "extendsjava" attribute on a CFC

[dgrabbe]

I just discovered that a CFC (in Railo) has the "extendsjava" option...very cool, if it does what I am hoping. Can this be used to create a CFC that extends a java interface, and have that CFC recognized as an implementation of that interface?

 

Here's what I am trying: I've got a conflictHandler.cfc file that "extendsjava" an interface (in this case, on from the SVNKit library):

 

 

<cfcomponent extendsjava="org.tmatesoft.svn.core.wc.ISVNConflictHandler">
 
 <cffunction name="init" returntype="any">
  <cfargument name="classLoader" type="any" required="true">
  
  <cfset variables.instance.classLoader = arguments.classLoader />
  
  <cfreturn this />
 </cffunction>
 
 
 <cffunction name="handleConflict" returntype="any">
  
  <cfset var svnConflictChoice = variables.instance.classLoader.create("org.tmatesoft.svn.core.wc.SVNConflictChoice") />
  <cfset var svnConflictResult = variables.instance.classLoader.create("org.tmatesoft.svn.core.wc.SVNConflictResult").init(svnConflictChoice.THEIRS_FULL, null) />
  
  <cfreturn svnConflictResult />
 </cffunction>
 

 

</cfcomponent>

 

 

...then I am creating one of these components, and trying to pass it in to an alread-create java component:

 

<cfset svnConflictHandler = createObject("component", "conflictHandler").init(classLoader = variables.instance.classLoader) />
<cfset svnOpts = svnUpdateClient.getOptions() />
<cfset svnOpts.setConflictHandler(svnConflictHandler) />

 

The "setCoflictHandler()" function expects an implementation of the org.tmatesoft.svn.core.wc.ISVNConflictHandler interface, which I thought I was giving it (because of the extendsjava option). But it is not recognizing the conflictHandler component as such -- it sees it as a struct. Here is the error it returns:

 

No matching Method/Function for org.tmatesoft.svn.core.internal.wc.DefaultSVNOptions.setConflictHandler(struct) found

 

Am I trying to use "extendsjava" the wrong way?

 

(For what its worth, I tried using JavaLoader's CFCDynamicProxy to cast a CFC as a java class, and it works fine with ACF, but not with Railo.)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Denny]

On 5/15/13 3:41 PM, dgrabbe wrote:
> I just discovered that a CFC (in Railo) has the "extendsjava" option...very
> cool, if it does what I am hoping. Can this be used to create a CFC that
> extends a java interface, and have that CFC recognized as an implementation
> of that interface?

Honestly I don't remember, but I think that may be for something else?
Regardless, you too should be able to use something like:

var cfConflictHandler = new conflictHandler();
var svnConflictHandler =
createDynamicProxy(cfConflictHandler,["org.tmatesoft.svn.core.wc.ISVNConflictHandler"]);

var svnOpts = svnUpdateClient.getOptions();
svnOpts.setConflictHandler(svnConflictHandler);

:Denny

--
Railo Technologies: getrailo.com Professional Open Source
Skype: valliantster (505)510.1336 de...@getrailo.com
GnuPG-FP: DDEB 16E1 EF43 DCFD 0AEE 5CD0 964B B7B0 1C22 CB62

[dgrabbe]

Nice -- I did not realize that createDynamicProxy is baked into Railo now.

 

I tried it, but somehow the object type is getting scrambled:

"No matching Method/Function for org.tmatesoft.svn.core.internal.wc.DefaultSVNOptions.setConflictHandler(Vde6d4083ce75d85c5245e64158edd55d5928) found"

 

Where is "Vde6d4083ce75d85c5245e64158edd55d5928" coming from?

[dgrabbe]

I've also tried on-the-fly java:

 

<cfscript language="java">
 ISVNConflictHandler conflictHandler = new ISVNConflictHandler() {
  public SVNConflictResult handleConflict(SVNConflictDescription conflictDescription) throws SVNException {
   return new SVNConflictResult(SVNConflictChoice.THEIRS_FULL, null);
  };
 };
 svnOpts.setConflictHandler(conflictHandler);
</cfscript>

 

 

...but I got the error "Missing [;] or [line feed] after expression"

 

 

On Wednesday, May 15, 2013 7:45:18 PM UTC-4, Denny Valliant wrote:

[Denny]

On 5/15/13 10:04 PM, dgrabbe wrote:
> Nice -- I did not realize that createDynamicProxy is baked into Railo now.
>
> I tried it, but somehow the object type is getting scrambled:
> "No matching Method/Function for
> org.tmatesoft.svn.core.internal.wc.DefaultSVNOptions.setConflictHandler(Vde6d4083ce75d85c5245e64158edd55d5928)
> found"
>
> Where is "Vde6d4083ce75d85c5245e64158edd55d5928" coming from?

I'm not sure. Can you post the code? If you slap it into github along
with an mxunit test or two, it would make it easy to assist. =)

[dgrabbe]

Thanks, Denny. It looks like "Vde6d4083ce75d85c5245e64158edd55d5928" is the class name being returned from the createDynamicProxy function.

 

Here's the code for conflictHandler.cfc:

 

<cfcomponent>
 
 <cffunction name="handleConflict" returntype="org.tmatesoft.svn.core.wc.SVNConflictChoice">
  
  <cfset var svnConflictChoice = createObject("java", "org.tmatesoft.svn.core.wc.SVNConflictChoice", "/SVNKit/lib/svnkit-1.7.8.jar") />
  <cfset var svnConflictResult = createObject("java", "org.tmatesoft.svn.core.wc.SVNConflictResult", "/SVNKit/lib/svnkit-1.7.8.jar").init(svnConflictChoice.THEIRS_FULL, JavaCast("null", "")) />
  
  <cfreturn svnConflictResult />
 </cffunction>
 

</cfcomponent>

 

...and here's how I am calling it:

 

<cfscript>

 var cfConflictHandler = new conflictHandler();
 var svnConflictHandler = createDynamicProxy(cfConflictHandler,["org.tmatesoft.svn.core.wc.ISVNConflictHandler"]); 

</cfscript>

 

I've attached a picture of the result when I call cfdump on these two objects. The second one (svnConflictHandler) comes back with a funky class name ("Vde6d4083ce75d85c5245e64158edd55d5928") instead of the expected "org.tmatesoft.svn.core.wc.ISVNConflictHandler".

 

(The only other thing you would need to test this is SVNKit: http://svnkit.com/download.php)

[Denny]

I forgot I actually have cfsvn, which I wrote years ago, that I can test
this on. It will be a bit before I can try it out, but in the meantime:

Try adding the dependencies to WEB-INF/lib instead of using the dynamic
classloading 3rd argument of createObject, or if you're using JavaLoader
(my favorite), use an isolated classloader with thread local switching,
perhaps similar to this:

https://github.com/cfmlprojects/cfhornetq/blob/master/src/cfhornetq/gateway/HornetQ.cfc

To insure that things are being found. Also, I might remove the java
return types from function calls, at least until you're sure they work
without it, as there may be oddness with type checking proxied cfcs.

In sum, try putting the libs in WEB-INF/lib and using plain
createObject("java","...") calls, if you haven't already.

[dgrabbe]

OK -- conflictHandler.cfc now looks like this:

 

<cfcomponent>
 <cffunction name="handleConflict" returntype="any">
  <cfset var svnConflictChoice = createObject("java", "org.tmatesoft.svn.core.wc.SVNConflictChoice") />
  <cfset var svnConflictResult = createObject("java", "org.tmatesoft.svn.core.wc.SVNConflictResult").init(svnConflictChoice.THEIRS_FULL, JavaCast("null", "")) />

  <cfreturn svnConflictResult />
 </cffunction>
</cfcomponent>

 

 I've added the SVNKit .jar path to catalina.properties, as well as to the Java Classpath (via the Apache Tomcat Railo Properties executable), dropped the .jar file in WEB-INF/railo/lib, and restarted the service.

...and the class name for the proxy object is still coming back as "Vde6d4083ce75d85c5245e64158edd55d5928"

 

 

Would CFSVN allow me to do what I'm trying to do with SVNKit -- do an update on a directory, and always have the repository version overwrite the working copy?

[Denny]

On 5/16/13 5:50 PM, dgrabbe wrote:
...

> I've added the SVNKit .jar path to catalina.properties, as well as to the
> Java Classpath (via the Apache Tomcat Railo Properties executable), dropped
> the .jar file in WEB-INF/railo/lib, and restarted the service.
> ...and the class name for the proxy object is still coming back as
> "Vde6d4083ce75d85c5245e64158edd55d5928"

Grrrr. :)

My jLine stuff for the CLI is working, haven't had a chance to test this
specific example though. Maybe there's something different about that
interface?

>
> Would CFSVN allow me to do what I'm trying to do with SVNKit -- do an
> update on a directory, and always have the repository version overwrite the
> working copy?

I think update+revert would result in that, so theoretically, yes. I'd
write a unit test for it, to be sure. :)