From dev-return-1127-apmail-freemarker-dev-archive=freemarker.apache.org@freemarker.incubator.apache.org Sat Mar 4 00:17:20 2017 Return-Path: X-Original-To: apmail-freemarker-dev-archive@minotaur.apache.org Delivered-To: apmail-freemarker-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4D8B319AF7 for ; Sat, 4 Mar 2017 00:17:20 +0000 (UTC) Received: (qmail 5311 invoked by uid 500); 4 Mar 2017 00:17:20 -0000 Delivered-To: apmail-freemarker-dev-archive@freemarker.apache.org Received: (qmail 5270 invoked by uid 500); 4 Mar 2017 00:17:20 -0000 Mailing-List: contact dev-help@freemarker.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@freemarker.incubator.apache.org Delivered-To: mailing list dev@freemarker.incubator.apache.org Received: (qmail 5252 invoked by uid 99); 4 Mar 2017 00:17:20 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Mar 2017 00:17:20 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 8BC40C05B2 for ; Sat, 4 Mar 2017 00:17:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.052 X-Spam-Level: *** X-Spam-Status: No, score=3.052 tagged_above=-999 required=6.31 tests=[KAM_THEBAT=1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_NEUTRAL=0.652] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id mXGkBwjU8hLD for ; Sat, 4 Mar 2017 00:17:17 +0000 (UTC) Received: from vie01a-dmta-pe01-1.mx.upcmail.net (vie01a-dmta-pe01-1.mx.upcmail.net [62.179.121.154]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 60C8A61F0A for ; Sat, 4 Mar 2017 00:17:06 +0000 (UTC) Received: from [172.31.216.44] (helo=vie01a-pemc-psmtp-pe02) by vie01a-dmta-pe01.mx.upcmail.net with esmtp (Exim 4.87) (envelope-from ) id 1cjxNa-0005zj-VK for dev@freemarker.incubator.apache.org; Sat, 04 Mar 2017 01:16:58 +0100 Received: from [192.168.0.3] ([89.132.92.167]) by vie01a-pemc-psmtp-pe02 with SMTP @ mailcloud.upcmail.net id rcGw1u00Z3cfLdl01cGxrX; Sat, 04 Mar 2017 01:16:57 +0100 X-SourceIP: 89.132.92.167 Date: Sat, 4 Mar 2017 01:16:53 +0100 From: Daniel Dekany X-Mailer: The Bat! (v4.2.36.4) Professional Reply-To: Daniel Dekany X-Priority: 3 (Normal) Message-ID: <814178050.20170304011653@freemail.hu> To: Woonsan Ko Subject: Re: [FM3] Opinions about the package structure? In-Reply-To: References: <1204066933.20170301200910@freemail.hu> <1216129488.20170303065443@freemail.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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. 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