freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <>
Subject Re: [FM3] Opinions about the package structure?
Date Wed, 08 Mar 2017 05:36:42 GMT
On Fri, Mar 3, 2017 at 7:16 PM, Daniel Dekany <> wrote:
> Saturday, March 4, 2017, 12:15:30 AM, Woonsan Ko wrote:
>> On Fri, Mar 3, 2017 at 12:54 AM, Daniel Dekany <> wrote:
> [snip]
>>> 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.

I see.

> 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
>    error.
>> 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
> freemarker-core-java-8).

Totally makes sense. Thanks a lot for sharing the full insights.



>> 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
> --
> Thanks,
>  Daniel Dekany

View raw message