freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re: [FM3] Opinions about the package structure?
Date Sat, 04 Mar 2017 00:16:53 GMT
Saturday, March 4, 2017, 12:15:30 AM, Woonsan Ko wrote:

> On Fri, Mar 3, 2017 at 12:54 AM, Daniel Dekany <> wrote:
>> or with Properties syntax:
>>   objectWrapper = DefaultObjectWrapper( \
>>      3.0.0, \
>>      typeHandlers=[ org.apache.freemarker.dom.DomTypeHandler ])
>> That's how users could add special treatment for their
>> application/domain specific types too (and if we switch to MOP-s, then
>> just replace objectWrapper with mopImplementationProvider or whatever
>> it will be called). So we are consistent with the idea that
>> freemarker-core only contains (and is aware of!) things that are
>> related to the core (minimal) functionality. But then, what are the
>> practical implications of the users? They get a freemarker-core.jar
>> that's a few kilobytes leaner, but in exchange they have to go through
>> the above extra configuring if they want to use the DOM wrapping. I'm
>> not sure if it worths it... mostly because I don't now how many
>> percentage of the users are using DOM wrapping. Certainly it's a
>> minority, a few percentages maybe, but it's just a wild guess.
> Could we let the core scan classpath resources from all the jar
> files

(The SPI feature of the Java platform does that, to be more precise.)

> (e.g, classpath:META-INF/org/apache/freemarker/core/TypeHandler) and
> register those handlers automatically? Then users will simply need
> to add extra dependencies such as dom and they can use it without
> any custom registration.

I don't think that activating a FreeMarker extension merely based on
its presence in the class path is acceptable, for most kind of
extensions. Real world projects easily use 100+ dependencies, most of
them being transitive (so you have never asked for them explicitly),
so practically, whether a particular jar (like freemarker-dom) appears
in the class path is out of your control.

The valid cases for automatically activating extensions are when
without the extension you simply ran into an error. Like FreeMarker
wants to wrap a java.time class, but freemarker-core-java-8 is
missing, that's an error, so we should auto-discover[*] that extension.
But with freemarker-dom, you can wrap DOM nodes without it, only they
will look different (like regular beans). So this extensions doesn't
prevent an error, but alters behavior, and thus I believe it must be
activated explicitly, independently for each Configuration.

BTW, when thinking about configuring FreeMarker, it should always be
considered that multiple independently developed components might use
FreeMarker internally. That's one reason why modifiable static fields
are wrong, and adding something to the classpath is very much like
that if it triggers some sort of auto-configuring.

*: Auto discovering of freemarker-core-java-8 is actually a special
   case, because freemarker-core already knows about it and looks for
   it itself (pull VS push basically). Because, it has to know that
   seeing a java.time object but not freemarker-core-java-8 is an

> I've seen something similar in Apache Camel. For example, when a
> custom Camel component is provided by a new jar file in the classpath,
> Camel engine automatically detects all the available component by
> scanning a dedicated classpath resource path [1], or it even scans all
> the type converters from provided jar files at runtime once [2].

I hope these are the error avoiding use cases though (as with

> If we can apply the same technique, then I guess users wouldn't have
> any difficulty. They can simply drop an optional jar files.
> Regards,
> Woonsan
> [1]
> [2]
>> --
>> Thanks,
>>  Daniel Dekany

 Daniel Dekany

View raw message