I wouldn’t recommend the approach you’re taking which is hacking the core of ColdBox. You won’t be able to upgrade your version of ColdBox now without reverting your changes.
Did you understand my approach? It would not involve modifying any code in the coldbox/system folder. You would be making your own version of coldbox.system.core.conversion.ObjectMarshaller that used a serialization scheme of your choosing. (I would skip the engine and algorithm detection for your purposes since you are NOT wanting different algorithms used) Then subclass the JDBCStore.cfc with an overridden init() method that sets your converter to override the default.
That is a much better way to extend CacheBox. You are asking for trouble by changing the interfaces as no other Cache Providers/Object Stores out there will work in your app any longer without you customizing them.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Right, but I thought you suggested that approach?
“Also, can you put in a ticket to make the JDBC store accept different convert objects as part of the config properties so you can override without subclassing?”
I totally agree with what you are saying and it would definitely lead to trouble when upgrading. I thought I would try that approach as I could see that it might be a good addition to the framework. It’s an edge-case but it’s definitely a scenario that could happen for other devs. I’m happy to contribute the changes i made if the CB team feels it’s a worthy approach. Sub-classing is a clean way to do it for now, but it would just be my implementation and not an approach to be contributed back to the platform.
I don’t want the JDBCStore.cfc to always use an overridden converter. I only need to use it selectively when caching certain objects. I use this store exclusively in an app and wouldn’t want all objects to use the railo converter. Having a config var in the set is a more extensible approach me thinks.
Regardless of the approach (subclass or not), there is still the stumbling point of how to serialize an object on one engine which can be read on another. That’s essentially the core issue.
Thanks!
N