Proposal: More control over "?new"

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: More control over "?new"

Daniel Dekany
As a few user has pointed out, the presence ?new is somewhat worrisome
in certain applications for security reasons, because it gives
"random" access to classes by name. Even if it only lets you
instantiate TemplateModel-s (so you can't create objects of arbitrary
classes), there can be still TemplateModel implementations around that
can be dangerous, or even just loading certain class with static can
be undesired due to the static initalizers. Yeah, it's a bit on the
paranoid side, but then consider when customers can edit templates...
they are not as trusted as the developers.

So I propose we add a Configuration-level setting called something
like "template_runtime_class_resolver", whose value will have to be a
ClassLoader object. This object would be used whenever an
FTL-construct (which is currently only ?new) tries to get a class by
name. This way, through a custom ClassLoader implementation, the user
can take control of which classes FreeMarker templates can access by
name, also if how those classes are get (like from which ClassLoader,
assuming the custom ClassLoader just delegates the task to other
ClassLoaders).

What do you think?

(BTW, I think "?new" is the only reason the FreeMarker OSGi bundle
needs that nasty "DynamicImport-Package: *". Is it? It still will be
needed... I just note that the "template_runtime_class_resolver" idea
seems to capture this aspect of scripting languages.)

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: More control over "?new"

Guo Du-4
On Mon, Aug 16, 2010 at 9:56 AM, Daniel Dekany <[hidden email]> wrote:
> So I propose we add a Configuration-level setting called something
> like "template_runtime_class_resolver", whose value will have to be a
> ClassLoader object. This object would be used whenever an
+1 A nice feature.

Once we have the capability to set class loader, we can remove the
"DynamicImport-Package: *" OSGi header and let user to control how
class will be loaded.

If ?new is the only use case of the class loader, would be the name
"user_defined_directive_class_loader" better than
"template_runtime_class_resolver" ?

Thanks!

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: More control over "?new"

Daniel Dekany
Monday, August 16, 2010, 11:40:47 AM, Guo Du wrote:

> On Mon, Aug 16, 2010 at 9:56 AM, Daniel Dekany <[hidden email]> wrote:
>> So I propose we add a Configuration-level setting called something
>> like "template_runtime_class_resolver", whose value will have to be a
>> ClassLoader object. This object would be used whenever an
> +1 A nice feature.
>
> Once we have the capability to set class loader, we can remove the
> "DynamicImport-Package: *" OSGi header and let user to control how
> class will be loaded.

I don't think it's realistic to expect users to craft a proper
ClassLoader just because they are using OSGi. That would mostly just
be a PITA for them. And indeed, if they are using OSGi but not
"DynamicImport-Package: *", then they should just use OSGi fragments
for this, rather than a FreeMarker-specific feature.

> If ?new is the only use case of the class loader, would be the name
> "user_defined_directive_class_loader" better than
> "template_runtime_class_resolver" ?

?new is not confined to loading directives, it can load whatever
TemplateModel-s. So then it would be
"user_defined_data_model_class_loader" (ugh... :) ). The reason I
don't want to be that specific with this setting name is that if you
look at FTL as a script language, it's possible that it will have more
features later that need this kind of stuff.

> Thanks!
>
> -Guo
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: More control over "?new"

Guo Du-4
2010/8/16 Daniel Dekany <[hidden email]>:
> I don't think it's realistic to expect users to craft a proper
> ClassLoader just because they are using OSGi. That would mostly just
> be a PITA for them. And indeed, if they are using OSGi but not
For most of the use case, the idea is not to create new class loader,
instead, the purpose is to be able to assign correct existing class
loader to FM. If no class loader setted, will just use default class
loader, then it could still get from "DynamicImport-Package: *".

> "user_defined_data_model_class_loader" (ugh... :) ). The reason I
> don't want to be that specific with this setting name is that if you
> look at FTL as a script language, it's possible that it will have more
> features later that need this kind of stuff.
Understand your point. I believe a meaningful name will help user and
dev to make use of the feature for long term. What about
extension_class_loader?

-Guo

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: More control over "?new"

Daniel Dekany
Monday, August 16, 2010, 11:38:45 PM, Guo Du wrote:

> 2010/8/16 Daniel Dekany <[hidden email]>:
>> I don't think it's realistic to expect users to craft a proper
>> ClassLoader just because they are using OSGi. That would mostly just
>> be a PITA for them. And indeed, if they are using OSGi but not
> For most of the use case, the idea is not to create new class loader,
> instead, the purpose is to be able to assign correct existing class
> loader to FM. If no class loader setted, will just use default class
> loader, then it could still get from "DynamicImport-Package: *".

Yes, that's how it would work. So the "DynamicImport-Package: *"
header remains, only it possibly will not be utilized.

>> "user_defined_data_model_class_loader" (ugh... :) ). The reason I
>> don't want to be that specific with this setting name is that if you
>> look at FTL as a script language, it's possible that it will have more
>> features later that need this kind of stuff.
> Understand your point. I believe a meaningful name will help user and
> dev to make use of the feature for long term.

Well, I will point to this setting in the documentation of ?new, also
describe that it influences ?new in the documentation of the setting.
Of course calling the setting 'new_builtin_class_loader' would be the
most helpful, but only until something else starts to use this setting
too, at which point the name becomes confusing instead.

> What about extension_class_loader?

Let alone that FM doesn't have anything that is called "extension",
take the fictional(?) example of a future usage of loading classes by
name from FTL: better handling of Java 5 enumerations with something
like 'com.example.Stuff.BAR'?enum. An enum constant is not something
that people would call an "extension".

> -Guo

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel