Re: Velocity + Spring MVC
On 6/2/19 2:06 PM, Michael Osipov wrote: > > wow, didn't expect Shibboleth still to be alive, I never understood > this entire complexity if there is Kerberos and TLs cert auth which > both served me well for the last 10 years at work. It's been very much alive for over 15 years, very widely used around the world in higher-ed and elsewhere. Kerberos and client TLS don't really address the same use cases as web SSO protocols like SAML and OIDC. But that's a topic for different list and/or off-list. > > As far as I remember Spring's codebase it covered a lot more than you > have in your Git repo. Yes, you are correct (although maybe not a *lot* more). My colleague who did that work didn't side-port quite everything, he omitted some things we don't use. I remembered this whilst doing some preliminary work on this on Sat and was going to report that, but you beat me to it. Apologies for the confusion. What I was proposing to do was do a complete port/migration of the Velocity support code in Spring's terminal 4.x release (currently 4.3.24.RELEASE). That would be the primary 'main' classpath code in these 2 packages from their 2 Maven modules: https://github.com/spring-projects/spring-framework/tree/v4.3.24.RELEASE/spring-context-support/src/main/java/org/springframework/ui/velocity https://github.com/spring-projects/spring-framework/tree/v4.3.24.RELEASE/spring-webmvc/src/main/java/org/springframework/web/servlet/view/velocity as well as related unit tests and some resource files. But it's still only 11 classes. So the scope of this isn't that large, unless I have missing something hiding in other packages or modules. > > How do they compare, would that be a drop-in replacement (except for > package/class names)? I was pretty much hoping to bring those over as-is as much as possible, so that the initial version would pretty much be a drop-in replacement for the existing code, with only package names changed. My colleague said he thought there were some changes for the Spring 4 -> 5 transition, but that is likely minimal. > We can start with small PRs and then grow by time. Ideally, It would > be a complete/better replacement of the previous Spring Velocity module. > If there's other features and capabilities that make sense to add, that is fine. Timewise I would personally advocate for getting a straight port of the existing functionality done and released first, to help out all the folks that want to update to Spring 5, but can't easily do so b/c they depend on Velocity. > as for the name, I wouldn't not call it velocity-tools-view-spring. > It it neither a tool from the Toolbox and neither tied to a view > since you can prduce anything textbased. It'd simply velocity-spring > covering all needs. > I'll defer to the Velocity devs for sensible module naming. Since the spring-context-support stuff is not MVC view related, and indeed Velocity is used for non-web template cases as you point out, I agree with omitting the "-view-" part. Aside from the name, I guess the main initial decision would be from which of the Velocity parent POMs should this inherit. Thanks, Brent
[jira] [Created] (VELTOOLS-182) MathTool.max longtime bug with args (0,0)
Sanford Whiteman created VELTOOLS-182:
-
Summary: MathTool.max longtime bug with args (0,0)
Key: VELTOOLS-182
URL: https://issues.apache.org/jira/browse/VELTOOLS-182
Project: Velocity Tools
Issue Type: Bug
Components: GenericTools
Affects Versions: 2.0
Reporter: Sanford Whiteman
It appears that {{$math.max}} has had a bug since at least 2.0, or at least I'm
at a loss as to why the observed behavior would be expected, and it doesn't
appear to be documented.
{code:java}
$math.max(0,0) {code}
returns
{code:java}
4.9E-324{code}
that is, Double.MIN_VALUE.
It's easy to see why in the source. Using
[3.0|https://apache.googlesource.com/velocity-tools/+/trunk/velocity-tools-generic/src/main/java/org/apache/velocity/tools/generic/MathTool.java#377]
here, we see:
{code:java}
public Number max(Object... nums)
{
double value = Double.MIN_VALUE;
Number[] ns = new Number[nums.length];
for (int i=0; i
Re: Velocity + Spring MVC
Hi Brent, Am 2019-06-01 um 02:32 schrieb Brent Putman: Hello, I represent the Shibboleth project (https://www.shibboleth.net/), a widely-used open-source platform for federated authentication (SAML, CAS, and soon OpenID Connect). We make heavy use of Velocity in our codebase, as well as Spring Framework and Spring MVC. wow, didn't expect Shibboleth still to be alive, I never understood this entire complexity if there is Kerberos and TLs cert auth which both served me well for the last 10 years at work. As you may know, in their v4.x the Spring folks decided to deprecate their internal Velocity support for the Spring MVC view layer in an effort to reduce their maintenance burden. Their (new) philosophy is that third-party libraries should include Spring support components in their projects, rather than the other way around. In Spring 5.x they completed this deprecation process by removing the Velocity view layer support components from Spring MVC entirely. More details on their thinking and reasoning here: https://github.com/spring-projects/spring-framework/issues/18368 My question: From the above issue comments, I see that at least one person from the Velocity project was aware of this. Does the Velocity team have any current plans in the works to add Spring MVC support components into the Velocity project as the Spring team advocates? I searched in the archives for this list going back awhile and didn't find anything, but apologies if I missed it. I do use Spring and Velocity as view with the two-pass approach in a web-based project. I have been watching the Spring Velocity deprecation ever since, but was not a committer back then. If not, then what we wanted to propose/discuss was essentially porting the latest, terminal Spring 4.x MVC Velocity components into the Velocity project. We could of course do this within our project internally (and have provisionally done so, see below), but there would seem to be significant value for the entire Velocity and Spring user communities for this to be more widely available and officially supported by the Velocity project itself. So the main purpose of this email is to gauge the level of interest in doing this (or conversely objections to doing so). The sketch of the proposal would be to add a new Velocity Tools Maven submodule (e.g. velocity-tools-view-spring), which would align with the existing Tools project organization. The scope of the code would likely be very similar to what you see here in our repo, which is how we are currently supporting development work on our next major version based on Spring 5: http://git.shibboleth.net/view/?p=spring-extensions.git;a=tree;f=src/main/java/net/shibboleth/ext/spring/velocity So it's a relatively small number of classes. If the interest here is positive, we would be fine with doing the initial work to produce a patch (unless someone on the Velocity team would prefer to do the work themselves of course). The main issue I suppose is the Velocity project taking on long-term support for these components. We look forward to hearing the Velocity developers' thoughts on this proposal. As far as I remember Spring's codebase it covered a lot more than you have in your Git repo. How do they compare, would that be a drop-in replacement (except for package/class names)? I'd be happy to take a look at it and compare, but due to time constraint I am not able to work actively on it -- as sad as it sounds. We can start with small PRs and then grow by time. Ideally, It would be a complete/better replacement of the previous Spring Velocity module. as for the name, I wouldn't not call it velocity-tools-view-spring. It it neither a tool from the Toolbox and neither tied to a view since you can prduce anything textbased. It'd simply velocity-spring covering all needs. Regards, Michael - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
[jira] [Commented] (VELOCITY-917) VTL Grammar Characters Configuration
[
https://issues.apache.org/jira/browse/VELOCITY-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853945#comment-16853945
]
Michael Osipov commented on VELOCITY-917:
-
What about having the user to provide a custom parser? This may no be a
perfect solution, but one w/o performance issues. You have to evaluate whether
this is possible at all:
Consider we provide a stub JavaCC definition file which can read the (custom)
token defition at compile time, thus the user has a distinct Maven module in
his build which contains a custom parser with his tokens and this one can be
plugged at start time into Velocity, if none provided we take our
{{DefaultParser.class}}. No runtime class modifications necessary.
> VTL Grammar Characters Configuration
>
>
> Key: VELOCITY-917
> URL: https://issues.apache.org/jira/browse/VELOCITY-917
> Project: Velocity
> Issue Type: New Feature
> Components: Engine
>Affects Versions: 2.2
>Reporter: Claude Brisson
>Assignee: Claude Brisson
>Priority: Major
>
> Experimental feature.
> The goal is to introduce new configuration parameters to be able to change
> the VTL grammar. For instance:
> parser.character.dollar = '~'
> parser.character.hash = '@'
> parser.character.arobase = '%'
> parser.character.star = '?'
> Requirements:
> + fully B.C.
> + done at runtime, without the need to recompile the parser
> + null impact on performance
> Implementation:
> 1. Parametrize code that needs explicit references to those characters
> 2. Define a ParserTokenManager interface and have the parser use this
> interface rather than a concrete class
> 3. Use a custom class loader to *patch* the concrete token manager .class
> file, instantiate this custom token manager and initialize parsers with it
> The binary patch is prepared at compilation time (there will be one patch per
> JRE vendor and class file version).
> Due to the limited capability of this technique, the chosen characters are
> restricted to UTF-8 single bytes characters. Patches _could_ be prepared for
> two-bytes or more characters, but there would be the need to have as many
> parser objects as variants in one/two/... characters combinations.
> Also, some characters and combinations are obviously invalid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
