[
https://issues.apache.org/jira/browse/JSPWIKI-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802147#action_12802147
]
Jürgen Weber commented on JSPWIKI-628:
--------------------------------------
The suggested mechanism would only make sense in core, else it would fail to
make deployment easier.
To counter your security concerns, one could check, that the downloadable
resource indeed is in the jar of the plugin:
URL resource = T.class.getResource("/antlr/ANTLRParser.class");
System.out.println(resource);
outputs
jar:file:/D:/eclipseworkspace/WikiExport/lib/antlr-2.7.7.jar!/antlr/ANTLRParser.class
So one would only have to check that the part before the ! would match.
> Load Plugin resources from classpath
> ------------------------------------
>
> Key: JSPWIKI-628
> URL: https://issues.apache.org/jira/browse/JSPWIKI-628
> Project: JSPWiki
> Issue Type: Improvement
> Affects Versions: 2.8.3
> Reporter: Jürgen Weber
>
> Some plugins require the browser to load files. E.g. the FreeMindPlugin needs
> the browser to load the applet's classes, or another plugin might need some
> flash code.
> Currently the solution is to attach these files to a page which has the sole
> purpose of having the attachment. This is kind of awkward.
> JSPWiki should have a mechanism (in JSPFilter?) which would load the file
> from the classpath. So for FreeMind the FreeMindPlugin.jar would additionally
> contain freemindbrowser.jar. The plugin would generate some markup that would
> make the Filter recognize that the parameter is to be loaded from classpath,
> e.g. <wiki:IncludeResource freemindbrowser.jar>
> I guess this could be done with a PageFilter, too, but the idea is to make
> installing plugins easier and having to add a filters.xml would be
> counterproductive, so the mechanism should go into core.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
