On Fri, Mar 3, 2017 at 7:16 PM, Daniel Dekany <[email protected]> wrote: > Saturday, March 4, 2017, 12:15:30 AM, Woonsan Ko wrote: > >> On Fri, Mar 3, 2017 at 12:54 AM, Daniel Dekany <[email protected]> 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.
Right. > > 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. Cheers, Woonsan > >> 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] http://camel.apache.org/how-do-i-add-a-component.html >> [2] >> http://camel.apache.org/type-converter.html#TypeConverter-DiscoveringTypeConverters >> >> >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >> > > -- > Thanks, > Daniel Dekany >
