New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make org.thymeleaf.Template serializable #378

Closed
candrews opened this Issue Jul 10, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@candrews

candrews commented Jul 10, 2015

Since org.thymeleaf.Template is cached, I think it should implement Serializable.

I think making this should should be pretty easy - perhaps it could be done for Thymeleaf 3?

Besides implementing the interface in org.thymeleaf.Template, it would also have to be added to these classes:
org.thymeleaf.dom.Document
org.thymeleaf.dom.DocType
and others.

Also, the fields:
org.thymeleaf.templateresolver.TemplateResolution.resourceResolver
org.thymeleaf.dom.Node.processors

should be removed and looked up on demand so that when those classes are serialized, the resourceResolver and processors aren't serialized too (since they don't change, and they're not serializable, they should not be serialized).

@candrews

This comment has been minimized.

Show comment
Hide comment
@candrews

candrews Jul 22, 2015

For folks that run into problems when using Ehcache ARC (Automatic Resource Allocation) due to this issue, I've written up how to work around it at http://candrews.integralblue.com/2015/07/issues-using-ehcache-with-arc-as-the-thymeleaf-cache/

candrews commented Jul 22, 2015

For folks that run into problems when using Ehcache ARC (Automatic Resource Allocation) due to this issue, I've written up how to work around it at http://candrews.integralblue.com/2015/07/issues-using-ehcache-with-arc-as-the-thymeleaf-cache/

@danielfernandez

This comment has been minimized.

Show comment
Hide comment
@danielfernandez

danielfernandez Jan 27, 2016

Member

I agree that once Templates are cacheable (in Thymeleaf 3.0 we would be talking about implementations of the org.thymeleaf.model.IModel interface) it would be desirable to make them implement java.io.Serializable.

Unfortunately, this is not possible with Thymeleaf 3.0's architecture and model implementations. For example (but not only), template engine events (implementations of org.thymeleaf.model.ITemplateEvent) contain references to template engine-wide structures such as the ITextRepository implementation they need to use to lazily initialize textual structures in memory when they are needed (and only then). Lazy initializations are almost everywhere in the new engine's model.

This kind of references cannot be easily converted into transient and re-initialized after deserialization because there might be more than one TemplateEngine instance in the same JVM, and everything in the engine's architecture is oriented towards supporting this kind of multi-engine, multi-configuration scenario. It's somehow similar to how Hibernate's still-not-hydrated dynamic proxies cannot retrieve a valid Hibernate session after a serialization + deserialization cycle: there is no way to know which session should be used (it might even live in a different server!).

So I'm closing this as declined, given I see no clear way of implementing this with the current or near-future engine architecture.

Thanks anyway.

Member

danielfernandez commented Jan 27, 2016

I agree that once Templates are cacheable (in Thymeleaf 3.0 we would be talking about implementations of the org.thymeleaf.model.IModel interface) it would be desirable to make them implement java.io.Serializable.

Unfortunately, this is not possible with Thymeleaf 3.0's architecture and model implementations. For example (but not only), template engine events (implementations of org.thymeleaf.model.ITemplateEvent) contain references to template engine-wide structures such as the ITextRepository implementation they need to use to lazily initialize textual structures in memory when they are needed (and only then). Lazy initializations are almost everywhere in the new engine's model.

This kind of references cannot be easily converted into transient and re-initialized after deserialization because there might be more than one TemplateEngine instance in the same JVM, and everything in the engine's architecture is oriented towards supporting this kind of multi-engine, multi-configuration scenario. It's somehow similar to how Hibernate's still-not-hydrated dynamic proxies cannot retrieve a valid Hibernate session after a serialization + deserialization cycle: there is no way to know which session should be used (it might even live in a different server!).

So I'm closing this as declined, given I see no clear way of implementing this with the current or near-future engine architecture.

Thanks anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment