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. 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 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). > 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
