JavaLoader Factory CFC, for ColdSpring, on GitHub

[Jamie Krug]

I put together a little JavaLoaderFactory.cfc to simplify instantiating JavaLoader in the server scope and making it available as a ColdSpring bean:

https://github.com/jamiekrug/JavaLoaderFactory

At its most basic/default usage it provides a factory method for ColdSpring, which accepts arguments identical to JavaLoader:init(). It creates (if needed) and returns a JavaLoader instance with a sensible server scope key that is unique to the instance (a hash of the JavaLoader:init() arguments).

The factory method has one additional optional argument, loadRelativePaths, which allows you to specify an array of _relative_ loadPaths (so you needn't expand them first).

You also have the option of specifying the server scope key, though I would not recommend it.

Check out the README file for a few more details and quick examples.

Please let me know if you find this at all useful or have any feedback.

Thanks,

Jamie

[Mark Mandel]

Took the thought out of my head jamie! Nice one :)

I was totally going to build exactly the same thing :)

I'll check it out, and will probably look at pulling it into Alpha 2 of CS2, as I've locked down features of Alpha 1.

Mark

Sent from my mobile device.

[Mark Mandel]

Jamie, as an interesting question - how come you didn't make it a FactoryBean, so that only the Javaloader object found in the server scope is exposed?

I.e. in CS2 it's:
http://coldspring.sourceforge.net/ber/docs/api/coldspring/coldspring/beans/factory/FactoryBean.html

Although is CS1.x has an inheritance hierarchy. Or did you not want it tied to ColdSpring (which I can understand as well)?

Mark

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

cf.Objective(ANZ) - Nov 17, 18 - Melbourne Australia
http://www.cfobjective.com.au

Hands-on ColdFusion ORM Training
www.ColdFusionOrmTraining.com

[Jamie Krug]

Ah, very interesting. I'm familiar with ColdSpring's ProxyFactoryBean and RemoteFactoryBean, but hadn't even thought to look at similar construct here, hence my non-ColdSpring-specific factory. That said, it seems silly not to do it, because ColdSpring is where I wanted JavaLoader to begin with. The CS2 FactoryBean interface makes perfect sense, but I'm not sure about CS1.x. You mention an inheritance hierarchy--I presume this just means you need to extend FactoryBean in 1.2, because it did not depend upon interfaces (which didn't exist in CFML at the time), but rather an "abstract" CFC, by convention?

In any case, is the behavior basically the same in both CS 1.2 and CS 2 alpha? If I understand correctly, but bean definition is completely normal, but ColdSpring knows to return the result of getObject() instead of the factory bean itself, as long as the bean class extends/implements FactoryBean?

I'll whip up a little prototype revision now. Just for style preference, do you think it would make sense to set properties in the bean definition to match JavaLoader's init args, or just have one map property hold those?

Thanks,

Jamie

[Jamie Krug]

How about something like this?

https://github.com/jamiekrug/JavaLoaderFactory/blob/7b0b4285b5fae7002f086bd958a705f75877ef9b/JavaLoaderFactoryBean.cfc

This works for ColdSpring 1.2, and it should work with ColdSpring 2.0 by merely using a component "implements" attribute in place of the "extends" attribute.

It seems that the named lock in getObject() is not likely necessary, but I see no harm either.

Best,
Jamie

[Mark Mandel]

Works nicely :)

Mark

[Jamie Krug]

Cool, it's working nicely for me in a ColdSpring 1.2 app. I'll clean up a CS2 version for you if you let me know how you'd like a patch. I assume I'd reference the coldspring.util.javaloader.JavaLoader CFC by default in CS2? I can also throw in hints to fit in with the CS2 style for ColdDocs. I forget--CF9+ for CS2 or CF8+?

Jamie

[Mark Mandel]

CS2 is CF8+

For providing patches - see:
http://sourceforge.net/apps/trac/coldspring/wiki/Collaboration

But that all sounds good. Cool stuff.

Mark

[Jamie Krug]

Great, sorry, totally missed that wiki page. I'll send a pull request soon. Cheers.

[Jamie Jackson]

It seems like it would be normal to manage Java singletons in ColdSpring as well, and I would think something like the following would be common practice.

I'm just looking for a sanity check/thoughts/suggestions, before I go forward full-steam.

CS snippet:

<bean id="javaLoaderFactory" class="lib.JavaLoaderFactory.JavaLoaderFactory" />

<bean id="javaLoader" factory-bean="javaLoaderFactory" factory-method="getJavaLoader">

<constructor-arg name="loadRelativePaths">

<list>

<value>/lib/pdfgen-1.1-jar-with-dependencies.jar</value>

</list>

</constructor-arg>

</bean>

<bean id="javaLoaderObjectFactory" class="lib.JavaLoaderFactory.JavaLoaderObjectFactory" autowire="byName" />

<bean id="pdfGenerator" factory-bean="javaLoaderObjectFactory" factory-method="create" autowire="byName">

<constructor-arg name="objectToCreate">

<value>com.icf.onecpd.pdfgen.PdfGenerator</value>

</constructor-arg>

</bean>

JavaLoaderObjectFactory:

component

accessors=true {

property javaLoader;

function init(javaLoader) {

setJavaLoader(arguments.javaLoader);

}

public any function create(string objectToCreate) {

return getJavaLoader().create(arguments.objectToCreate);

}

}

Thanks,

Jamie 2 (Electric Boogaloo)

[Jamie Jackson]

Whoops, JavaLoader is a factory already, so forget my spurious factory component, and consider this, instead:

<bean id="pdfGenerator" factory-bean="javaLoader" factory-method="create" autowire="byName">

<constructor-arg name="className">

<value>com.icf.onecpd.pdfgen.PdfGenerator</value>

</constructor-arg>

</bean>

[Chris Blackwell]

Yep, nothing wrong with that.

--
You received this message because you are subscribed to the Google Groups "javaloader-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaloader-de...@googlegroups.com.
To post to this group, send email to javaloa...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaloader-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jamie Jackson]

Actually maybe my javaLoader factory is a good idea.

Here's what I want to do: I want to set properties on my JavaLoader-loaded object in ColdSpring:

<bean id="javaLoaderFactory" class="lib.JavaLoaderFactory.JavaLoaderFactory">

<constructor-arg name="javaLoaderDotPath">

<value>lib.javaloader.JavaLoader</value>

</constructor-arg>

</bean>

<bean id="javaLoader" factory-bean="javaLoaderFactory" factory-method="getJavaLoader">

<constructor-arg name="loadRelativePaths">

<list>

<value>/plugins/incomecalculator/lib/pdfgen-1.1-jar-with-dependencies.jar</value>

</list>

</constructor-arg>

</bean>

<bean id="javaLoaderObjectFactory" class="lib.JavaLoaderFactory.JavaLoaderObjectFactory" autowire="byName">

<constructor-arg name="javaLoader"><ref bean="javaLoader" /></constructor-arg>

</bean>

<bean id="pdfGenerator" factory-bean="javaLoaderObjectFactory" factory-method="create" autowire="byName">

<constructor-arg name="objectToCreate">

<value>com.icf.onecpd.pdfgen.PdfGenerator</value>

</constructor-arg>

<constructor-arg name="properties" >

<map>

<entry key="templatesPath"><value>/incomecalculator/public/pdf_templates/</value></entry>

</map>

</constructor-arg>

</bean>

javaLoaderObjectFactory:

component

accessors=true {

property javaLoader;

function init(javaLoader) {

setJavaLoader(arguments.javaLoader);

}

public any function create(string objectToCreate, struct properties = {}) {

var obj = getJavaLoader().create(arguments.objectToCreate);

return populate(obj, arguments.properties);

}

public any function populate(object, required struct memento){

var bu = createObject("java", "org.apache.commons.beanutils.BeanUtils");

bu.populate(object, memento);

// writeDump(var=memento.getClass(), abort=true); //object.getTemplatesPath(),

return object;

}

}

But, my Java is rusty, so I'm not sure how to populate the Java object generically.

I'd gues it's common thing to want to set some properties of a JavaLoader-loaded object in ColdSpring. Is there some more elegant/standard way to do it? Am I on the right track?

Thanks,

Jamie

On Monday, March 11, 2013 9:37:40 AM UTC-4, Jamie Jackson wrote:

[Jamie Krug]

On Mon, Mar 11, 2013 at 9:37 AM, Jamie Jackson <jamie...@gmail.com> wrote:

It seems like it would be normal to manage Java singletons in ColdSpring as well, and I would think something like the following would be common practice.

Certainly. I'm using DI/1 in an app right now, and I do just that -- use JavaLoader to grab an instance of the Java object and just add it as a (singleton) bean to the bean factory.

[Jamie Jackson]

Do you have any tricks for creating a generic object factory (which will set properties on the object)?

I tried to implement a "populate" function using org.apache.commons.beanutils.BeanUtils.populate(), but it didn't have any effect on the object:

component

accessors=true {

property javaLoader;

function init(javaLoader) {

setJavaLoader(arguments.javaLoader);

}

public any function create(string objectToCreate, struct properties = {}) {

var obj = getJavaLoader().create(arguments.objectToCreate);

return populate(obj, arguments.properties);

}

public any function populate(object, required struct memento){

var bu = createObject("java", "org.apache.commons.beanutils.BeanUtils");

bu.populate(object, memento);

// writeDump(var=memento.getClass(), abort=true); //object.getTemplatesPath(),

return object;

}

}

[Jamie Krug]

Sorry, nothing off the top of my head. That BeanUtils options seems to make sense, but I haven't used it recently. It seems that it should work if your object has getters/setters for properties.

--