[jira] [Commented] (VELOCITY-952) Velocity is calling the "wrong" method

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772341#comment-17772341
 ] 

Christopher Schultz commented on VELOCITY-952:
--

I reported this as VELOCITY-968 and offered the following as a suggestion. I 
don't know how the introspector works, so I'm just waving my hands, here:

"

Maybe 
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List, 
Class[]) can choose a superclass method over a subclass method if they are 
otherwise equivalent?

"

I've read the documentation for MethodOverrideUberspector.java and I think if 
you just always use the most-superclass-or-superinterface method available, 
many of these issues can be avoided without any additional overhead of 
remembering the return-type of certain "get" invocations. This will also help 
when Velocity wasn't responsible for performing the original access, for 
example when the object is just dropped into the context by Java code and has a 
runtime type different from the declared type in the code.

> Velocity is calling the "wrong" method
> --
>
> Key: VELOCITY-952
> URL: https://issues.apache.org/jira/browse/VELOCITY-952
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 2.3
>Reporter: Thomas Mortagne
>Priority: Major
>
> OK, the title is maybe a bit harsh, but it catches the eyes :)
> At XWiki we recently started testing on Java 17 to see if there is any 
> problem which leaded us to add things like {{--add-opens 
> java.base/java.util=ALL-UNNAMED}} but Velocity happen to be the source of 
> another problem related to the new module world.
> When doing something like {{$datetool.timeZone.getOffset(0)}} ($datetool 
> being the org.apache.velocity.tools.generic.DateTool) we get the following 
> error:
> {noformat}
> ...
> Caused by: java.lang.IllegalAccessException: class 
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl cannot 
> access class sun.util.calendar.ZoneInfo (in module java.base) because module 
> java.base does not export sun.util.calendar to unnamed module @7ca16adc
>  at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>  at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
>  at java.base/java.lang.reflect.Method.invoke(Method.java:560)
>  at 
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:571)
>  at 
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:554)
>  at 
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:221)
>  ... 199 more
> {noformat}
> The reason is that while the developer intent/expectation was to call 
> "java.util.TimeZone#getOffset(0)" what Velocity really called from JVM point 
> of view is "sun.util.calendar.ZoneInfo.getOffset(0)" directly.
> That's because Velocity is doing (I assume, since I did not check the exact 
> code) the equivalent of:
> {noformat}
> java.util.TimeZone.getDefault().getClass().getMethod("getOffset", 
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which is itself the equivalent of:
> {noformat}
> sun.util.calendar.ZoneInfo.class.getMethod("getOffset", 
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> I guess the only way to fix this would be to track down the lowest overridden 
> Method (I agree, it might not always be easy to choose between two interfaces 
> declaring a method with the same signature, but choosing the first one we 
> find from the same hierarchy level is still better than nothing) and call 
> that one instead. With the use case used as example in this issue, that would 
> mean ending up doing the equivalent of:
> {noformat}
> java.util.TimeZone.class.getMethod("getOffset", 
> long.class).invoke(TimeZone.getDefault(), 0);
> {noformat}
> which, from JVM point of view, is covered by the {{--add-opens 
> java.base/java.util=ALL-UNNAMED}}.
> It would be a big change, but at least can't think of any retro-compatibility 
> problem it might cause.
> One might be tempted to answer "just add {{--add-opens 
> java.base/sun.util.calendar=ALL-UNNAMED}}" but it does not seem fair as this 
> is not what the API that the script uses was exposing at all, you might need 
> to document a different one for each JVM implementation (even if it's 
> probably unlikely for this specific example) but more importantly you will 
> potentially need quite a lot of 

[jira] [Resolved] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELOCITY-968.
--
Resolution: Duplicate

Duplicate of VELOCITY-952

> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>    Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an 
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.velocity.runtime.parser.node.PropertyExecutor 
> (file:.../velocity-engine-core-2.3.jar) to method 
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException: 
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in 
> class sun.security.x509.X509CertImpl
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
>     at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
>     at org.apache.velocity.Template.merge(Template.java:358)
>     at org.apache.velocity.Template.merge(Template.java:262)
>     at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class 
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
> sun.security.x509.X509CertImpl (in module java.base) because module java.base 
> does not export sun.security.x509 to unnamed module @45ad6cad
>     at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>     at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:560)
>     at 
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
>     at 
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
>     ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its 
> method invocation.
>  
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
>   private static final String certText = "-BEGIN CERTIFICATE-\n"
>     + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
>     + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
>     + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
>     + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
>     + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
>

[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772338#comment-17772338
 ] 

Christopher Schultz commented on VELOCITY-968:
--

Yes, it does indeed look like a duplicate. Apologies. I did search, but the 
description of VELOCITY-952 didn't seem to match and I didn't read the details.

> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>    Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an 
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.velocity.runtime.parser.node.PropertyExecutor 
> (file:.../velocity-engine-core-2.3.jar) to method 
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException: 
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in 
> class sun.security.x509.X509CertImpl
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
>     at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
>     at org.apache.velocity.Template.merge(Template.java:358)
>     at org.apache.velocity.Template.merge(Template.java:262)
>     at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class 
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
> sun.security.x509.X509CertImpl (in module java.base) because module java.base 
> does not export sun.security.x509 to unnamed module @45ad6cad
>     at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>     at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:560)
>     at 
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
>     at 
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
>     ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its 
> method invocation.
>  
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
>   private static final String certText = "-BEGIN CERTIFICATE-\n"
>     + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
>     + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
>     + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
>     + "Fw0yMzEwMDUxNzQyMzJaFw

[jira] [Comment Edited] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772335#comment-17772335
 ] 

Christopher Schultz edited comment on VELOCITY-968 at 10/5/23 6:28 PM:
---

Maybe 
org.apache.velocity.util.introspection.MethodMap.getBestMatch(List, 
Class[]) can choose a superclass method over a subclass method if they are 
otherwise equivalent?


was (Author: ch...@christopherschultz.net):
Maybe 
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List, 
Class[])` can choose a superclass method over a subclass method if they are 
otherwise equivalent?

> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>    Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an 
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.velocity.runtime.parser.node.PropertyExecutor 
> (file:.../velocity-engine-core-2.3.jar) to method 
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException: 
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in 
> class sun.security.x509.X509CertImpl
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
>     at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
>     at org.apache.velocity.Template.merge(Template.java:358)
>     at org.apache.velocity.Template.merge(Template.java:262)
>     at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class 
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
> sun.security.x509.X509CertImpl (in module java.base) because module java.base 
> does not export sun.security.x509 to unnamed module @45ad6cad
>     at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>     at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:560)
>     at 
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
>     at 
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
>     ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its 
> method invocation.
>  
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
>   private static final String certText = "-BEGIN CERTIFICATE-\n"
>     + "MIICJTCC

[jira] [Commented] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772335#comment-17772335
 ] 

Christopher Schultz commented on VELOCITY-968:
--

Maybe 
`org.apache.velocity.util.introspection.MethodMap.getBestMatch(List, 
Class[])` can choose a superclass method over a subclass method if they are 
otherwise equivalent?

> In Java 17+, introspection fails in many cases due to permissions
> -
>
> Key: VELOCITY-968
> URL: https://issues.apache.org/jira/browse/VELOCITY-968
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7.x, 2.3
> Environment: Java 17
>    Reporter: Christopher Schultz
>Priority: Major
>
> When running under Java 17 or later, introspection often picks an 
> inaccessible method on a runtime object, which then fails when invoked.
> For example, running the example below under Java 8, the output is simple:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 11 or later, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.velocity.runtime.parser.node.PropertyExecutor 
> (file:.../velocity-engine-core-2.3.jar) to method 
> sun.security.x509.X509CertImpl.getNotAfter()
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.velocity.runtime.parser.node.PropertyExecutor
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Test: Wed Jan 03 12:42:32 EST 2024
> {noformat}
> When running on Java 17, we get:
> {noformat}
> Cert notAfter=Wed Jan 03 12:42:32 EST 2024
> Exception in thread "main" org.apache.velocity.exception.VelocityException: 
> ASTIdentifier() : exception invoking method for identifier 'notAfter' in 
> class sun.security.x509.X509CertImpl
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
>     at 
> org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
>     at 
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
>     at org.apache.velocity.Template.merge(Template.java:358)
>     at org.apache.velocity.Template.merge(Template.java:262)
>     at CertTest.main(CertTest.java:52)
> Caused by: java.lang.IllegalAccessException: class 
> org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
> sun.security.x509.X509CertImpl (in module java.base) because module java.base 
> does not export sun.security.x509 to unnamed module @45ad6cad
>     at 
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
>     at 
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
>     at java.base/java.lang.reflect.Method.invoke(Method.java:560)
>     at 
> org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
>     at 
> org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
>     at 
> org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
>     ... 6 more
> {noformat}
> It looks like Velocity is picking an inconvenient class on which to base its 
> method invocation.
>  
> Here is the test source.
> {noformat}
> import java.io.OutputStreamWriter;
> import java.io.StringReader;
> import java.nio.charset.StandardCharsets;
> import java.security.cert.Certificate;
> import java.security.cert.X509Certificate;
> import java.security.cert.CertificateFactory;
> import org.apache.velocity.Template;
> import org.apache.velocity.VelocityContext;
> import org.apache.velocity.app.VelocityEngine;
> import org.apache.velocity.runtime.RuntimeServices;
> import org.apache.velocity.runtime.RuntimeSingleton;
> public class CertTest {
>   private static final String certText = "-BEGIN CERTIFICATE-\n"
>     + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
>     + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
>     + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGV

[jira] [Updated] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz updated VELOCITY-968:
-
Description: 
When running under Java 17 or later, introspection often picks an inaccessible 
method on a runtime object, which then fails when invoked.

For example, running the example below under Java 8, the output is simple:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 11 or later, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
org.apache.velocity.runtime.parser.node.PropertyExecutor 
(file:.../velocity-engine-core-2.3.jar) to method 
sun.security.x509.X509CertImpl.getNotAfter()
WARNING: Please consider reporting this to the maintainers of 
org.apache.velocity.runtime.parser.node.PropertyExecutor
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 17, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Exception in thread "main" org.apache.velocity.exception.VelocityException: 
ASTIdentifier() : exception invoking method for identifier 'notAfter' in class 
sun.security.x509.X509CertImpl
    at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
    at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
    at 
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
    at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
    at org.apache.velocity.Template.merge(Template.java:358)
    at org.apache.velocity.Template.merge(Template.java:262)
    at CertTest.main(CertTest.java:52)
Caused by: java.lang.IllegalAccessException: class 
org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
sun.security.x509.X509CertImpl (in module java.base) because module java.base 
does not export sun.security.x509 to unnamed module @45ad6cad
    at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
    at 
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
    at java.base/java.lang.reflect.Method.invoke(Method.java:560)
    at 
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
    at 
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
    at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
    ... 6 more
{noformat}
It looks like Velocity is picking an inconvenient class on which to base its 
method invocation.

 

Here is the test source.
{noformat}
import java.io.OutputStreamWriter;
import java.io.StringReader;
import java.nio.charset.StandardCharsets;
import java.security.cert.Certificate;
import java.security.cert.X509Certificate;
import java.security.cert.CertificateFactory;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.RuntimeSingleton;

public class CertTest {
  private static final String certText = "-BEGIN CERTIFICATE-\n"
    + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
    + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
    + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
    + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
    + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
    + "B1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xDTALBgNVBAMTBHRlc3QwdjAQBgcq\n"
    + "hkjOPQIBBgUrgQQAIgNiAARluamNquFohhtrjhN6Sq+QXVlb+/1GVHg0h10iDehm\n"
    + "msRkfPkugLIwRbLIaggzFkx66QcT4oIjhvM0Q1jM7a/9BhNUWJvZMa54M3Nh+K6P\n"
    + "fzp8tOGHe2EAHibDP1KSGHCjITAfMB0GA1UdDgQWBBSLy96Os2mUo7TiKAwRlEmq\n"
    + "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
    + "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
    + "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
    + "-END CERTIFICATE-\n"
;

  private static final String templateText = "Test: $cert.notAfter\n";

  public static void main(String[] args) throws Exception {
    X509Certificate cert = 
(X509Certificate)CertificateFactory.getInstance("X.509").generateCertificate(new
 java.io.ByteArrayInputStream(certText.getBytes(StandardCharsets.US_ASCII

[jira] [Created] (VELOCITY-968) In Java 17+, introspection fails in many cases due to permissions

[Christopher Schultz (Jira)]

Christopher Schultz created VELOCITY-968:


 Summary: In Java 17+, introspection fails in many cases due to 
permissions
 Key: VELOCITY-968
 URL: https://issues.apache.org/jira/browse/VELOCITY-968
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 2.3, 1.7.x
 Environment: Java 17
Reporter: Christopher Schultz


When running under Java 17 or later, introspection often picks an inaccessible 
method on a runtime object, which then fails when invoked.

For example, running the example below under Java 8, the output is simple:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 11 or later, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
org.apache.velocity.runtime.parser.node.PropertyExecutor 
(file:/Users/christopherschultz/Documents/Eclipse/chadis-web/velocity-engine-core-2.3.jar)
 to method sun.security.x509.X509CertImpl.getNotAfter()
WARNING: Please consider reporting this to the maintainers of 
org.apache.velocity.runtime.parser.node.PropertyExecutor
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Test: Wed Jan 03 12:42:32 EST 2024
{noformat}
When running on Java 17, we get:
{noformat}
Cert notAfter=Wed Jan 03 12:42:32 EST 2024
Exception in thread "main" org.apache.velocity.exception.VelocityException: 
ASTIdentifier() : exception invoking method for identifier 'notAfter' in class 
sun.security.x509.X509CertImpl
    at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:282)
    at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:368)
    at 
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:492)
    at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:439)
    at org.apache.velocity.Template.merge(Template.java:358)
    at org.apache.velocity.Template.merge(Template.java:262)
    at CertTest.main(CertTest.java:52)
Caused by: java.lang.IllegalAccessException: class 
org.apache.velocity.runtime.parser.node.PropertyExecutor cannot access class 
sun.security.x509.X509CertImpl (in module java.base) because module java.base 
does not export sun.security.x509 to unnamed module @45ad6cad
    at 
java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
    at 
java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
    at java.base/java.lang.reflect.Method.invoke(Method.java:560)
    at 
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:149)
    at 
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:722)
    at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:217)
    ... 6 more
{noformat}
It looks like Velocity is picking an inconvenient class on which to base its 
method invocation.

 

Here is the test source.
{noformat}
import java.io.OutputStreamWriter;
import java.io.StringReader;
import java.nio.charset.StandardCharsets;
import java.security.cert.Certificate;
import java.security.cert.X509Certificate;
import java.security.cert.CertificateFactory;
import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.RuntimeSingleton;

public class CertTest {
  private static final String certText = "-BEGIN CERTIFICATE-\n"
    + "MIICJTCCAaygAwIBAgIIXjahgh5+v08wCgYIKoZIzj0EAwMwaTEQMA4GA1UEBhMH\n"
    + "VW5rbm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4G\n"
    + "A1UEChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjENMAsGA1UEAxMEdGVzdDAe\n"
    + "Fw0yMzEwMDUxNzQyMzJaFw0yNDAxMDMxNzQyMzJaMGkxEDAOBgNVBAYTB1Vua25v\n"
    + "d24xEDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoT\n"
    + "B1Vua25vd24xEDAOBgNVBAsTB1Vua25vd24xDTALBgNVBAMTBHRlc3QwdjAQBgcq\n"
    + "hkjOPQIBBgUrgQQAIgNiAARluamNquFohhtrjhN6Sq+QXVlb+/1GVHg0h10iDehm\n"
    + "msRkfPkugLIwRbLIaggzFkx66QcT4oIjhvM0Q1jM7a/9BhNUWJvZMa54M3Nh+K6P\n"
    + "fzp8tOGHe2EAHibDP1KSGHCjITAfMB0GA1UdDgQWBBSLy96Os2mUo7TiKAwRlEmq\n"
    + "dzOrCDAKBggqhkjOPQQDAwNnADBkAjBx+sqV2gzUusdOvwltH7f7sp5UtZMRFKF4\n"
    + "mRcGA7buAZN/YPUGgkiUZ6ZEJmw8Dn8CMEEgm8c2WTYdO/CQ5DRBbfIt1TcpiDxk\n"
    + "0vM+YZrSctwCJhK+3h3i4X990XvjJQ3Hmw==\n"
    + "-END CERTIFICATE-\n"
;

  private static final Str

[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636051#comment-17636051
 ] 

Christopher Schultz commented on VELTOOLS-184:
--

I stand corrected.

> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
>  Issue Type: Improvement
>  Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
>  Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant 
> with the JSON syntax. For instance, when the input string contains an 
> apostrophe ', a backslash is inserted before it because there is no way for 
> the method to know if the string is enclosed with single or double quotes. 
> This is not compliant with the JSON syntax, and some JSON parsers will reject 
> the string.
> There may be other differences between javascript and JSON strings, but this 
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second 
> javascript method with a second parameter indicating the type of quote used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Comment Edited] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635999#comment-17635999
 ] 

Christopher Schultz edited comment on VELTOOLS-184 at 11/18/22 7:12 PM:


I'm sorry, but whatever JSON parser you are working with is patently broken.

Quoting [RFC 4627, section 
2.5|https://www.ietf.org/rfc/rfc4627.html#section-2.5]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library 
is broken{_}.

 


was (Author: ch...@christopherschultz.net):
I'm sorry, but whatever JSON parser you are working with is patently broken.

Quoting [RFC 4627, section 
2.5|[http://example.com|https://www.ietf.org/rfc/rfc4627.html#section-2.5]]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library 
is broken{_}.

 

> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
>  Issue Type: Improvement
>  Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
>  Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant 
> with the JSON syntax. For instance, when the input string contains an 
> apostrophe ', a backslash is inserted before it because there is no way for 
> the method to know if the string is enclosed with single or double quotes. 
> This is not compliant with the JSON syntax, and some JSON parsers will reject 
> the string.
> There may be other differences between javascript and JSON strings, but this 
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second 
> javascript method with a second parameter indicating the type of quote used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-184) EscapeTool: add a json method, or a javascript method with a second parameter

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635999#comment-17635999
 ] 

Christopher Schultz commented on VELTOOLS-184:
--

I'm sorry, but whatever JSON parser you are working with is patently broken.

Quoting [RFC 4627, section 
2.5|[http://example.com|https://www.ietf.org/rfc/rfc4627.html#section-2.5]]:
{quote}Any character may be escaped.
{quote}
So, breaking when ' is (perhaps unexpectedly) escaped means that {_}the library 
is broken{_}.

 

> EscapeTool: add a json method, or a javascript method with a second parameter
> -
>
> Key: VELTOOLS-184
> URL: https://issues.apache.org/jira/browse/VELTOOLS-184
> Project: Velocity Tools
>  Issue Type: Improvement
>  Components: GenericTools
>Affects Versions: 2.x
> Environment: any
>Reporter: Maurice Perry
>Priority: Minor
>  Labels: EscapeTool, escape, javascript, json
>
> The string returned by EscapeTool.javascript() method is not alway compliant 
> with the JSON syntax. For instance, when the input string contains an 
> apostrophe ', a backslash is inserted before it because there is no way for 
> the method to know if the string is enclosed with single or double quotes. 
> This is not compliant with the JSON syntax, and some JSON parsers will reject 
> the string.
> There may be other differences between javascript and JSON strings, but this 
> is the one I encountered, and I had to use a workaround.
> This issue can be solved either with a JSON method, or with a second 
> javascript method with a second parameter indicating the type of quote used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Updated] (VELTOOLS-196) MathTool.matchType can truncate integral values

[Christopher Schultz (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz updated VELTOOLS-196:
-
Description: 
I found this while trying to create random numbers with a huge range. Without 
thinking too hard about it, I did:

$math.random(1,)

That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. 
The result is that my random number is _always_ Long.MAX_VALUE.

I tracked this down to MathTool.random's use of MathTool.matchType, which 
returns either an Integer or a Long value, depending upon whether the 
value-to-match-types is outside the range of [ Integer.MIN_VALUE - 
Integer.MAX_VALUE ].

Well, there are double values which are higher than Long.MAX_VALUE, too, and 
those should return a BigInteger value instead of a Long.

If I call $math.toNumber(), I get a BigInteger and so I'd 
expect that MathTool.random() would be able to return a BigInteger as well.

So I think we just need another clause which checks to see if Long isn't big 
enough, and return a BigInteger instead.

(We might want to think about supporting BigDouble, too, but that's outside the 
scope of this bug report.)

  was:
I found this while trying to create random numbers with a huge range. Without 
thinking too hard about it, I did:

$math.random(1,)

That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. 
The result is that my random number is always Long.MAX_DOUBLE.

I tracked this down to MathTool.random's use of MathTool.matchTypes, which 
returns either an Integer or a Long value, depending upon whether the 
value-to-match-types is outside the range of [ Integer.MIN_VALUE - 
Integer.MAX_VALUE ].

Well, there are double values which are higher than Long.MAX_VALUE, too, and 
those should return a BigInteger value instead of a Long.

If I call $math.toNumber(), I get a BigInteger and so I'd 
expect that MathTool.random() would be able to return a BigInteger as well.

So I think we just need another clause which checks to see if Long isn't big 
enough, and return a BigInteger instead.

(We might want to think about supporting BigDouble, too, but that's outside the 
scope of this bug report.)


> MathTool.matchType can truncate integral values
> ---
>
> Key: VELTOOLS-196
> URL: https://issues.apache.org/jira/browse/VELTOOLS-196
> Project: Velocity Tools
>  Issue Type: Bug
>Affects Versions: 3.1
>    Reporter: Christopher Schultz
>Priority: Minor
>
> I found this while trying to create random numbers with a huge range. Without 
> thinking too hard about it, I did:
> $math.random(1,)
> That's 20 nines all lined-up, which turns out to be larger than 
> Long.MAX_VALUE. The result is that my random number is _always_ 
> Long.MAX_VALUE.
> I tracked this down to MathTool.random's use of MathTool.matchType, which 
> returns either an Integer or a Long value, depending upon whether the 
> value-to-match-types is outside the range of [ Integer.MIN_VALUE - 
> Integer.MAX_VALUE ].
> Well, there are double values which are higher than Long.MAX_VALUE, too, and 
> those should return a BigInteger value instead of a Long.
> If I call $math.toNumber(), I get a BigInteger and so I'd 
> expect that MathTool.random() would be able to return a BigInteger as well.
> So I think we just need another clause which checks to see if Long isn't big 
> enough, and return a BigInteger instead.
> (We might want to think about supporting BigDouble, too, but that's outside 
> the scope of this bug report.)



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-196) MathTool.matchType can truncate integral values

[Christopher Schultz (Jira)]

Christopher Schultz created VELTOOLS-196:


 Summary: MathTool.matchType can truncate integral values
 Key: VELTOOLS-196
 URL: https://issues.apache.org/jira/browse/VELTOOLS-196
 Project: Velocity Tools
  Issue Type: Bug
Affects Versions: 3.1
Reporter: Christopher Schultz


I found this while trying to create random numbers with a huge range. Without 
thinking too hard about it, I did:

$math.random(1,)

That's 20 nines all lined-up, which turns out to be larger than Long.MAX_VALUE. 
The result is that my random number is always Long.MAX_DOUBLE.

I tracked this down to MathTool.random's use of MathTool.matchTypes, which 
returns either an Integer or a Long value, depending upon whether the 
value-to-match-types is outside the range of [ Integer.MIN_VALUE - 
Integer.MAX_VALUE ].

Well, there are double values which are higher than Long.MAX_VALUE, too, and 
those should return a BigInteger value instead of a Long.

If I call $math.toNumber(), I get a BigInteger and so I'd 
expect that MathTool.random() would be able to return a BigInteger as well.

So I think we just need another clause which checks to see if Long isn't big 
enough, and return a BigInteger instead.

(We might want to think about supporting BigDouble, too, but that's outside the 
scope of this bug report.)



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELOCITY-949) Extra whitespaces in converting from Word to PDF

[Christopher Schultz (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELOCITY-949.
--
Resolution: Duplicate

> Extra whitespaces in converting from Word to PDF
> 
>
> Key: VELOCITY-949
> URL: https://issues.apache.org/jira/browse/VELOCITY-949
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Reporter: Ivan Galkin
>Priority: Major
>
> I need to convert text from Word to PDF using "if" construction of Velocity. 
> When I use it, i have an extra space before the value of if construction. How 
> can I get rid of it?
> Example:
> In Word it looks like: «#if(xxx == "true)»1«#else»0«#end»
> But in PDF we will get:
>   1
> Instead of:
> 1



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELOCITY-950) Skipping empty lines

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481889#comment-17481889
 ] 

Christopher Schultz commented on VELOCITY-950:
--

[~igalkin98] Just remove the completely blank line between your statements and 
the completely blank line in your output will disappear.

Likewise, if you want the newlines to disappear, then remove the newlines from 
your template. If you are desperate, then add ## to the end of each of your 
lines where you have a newline you don't want to appear in your output.

There is no bug here.

> Skipping empty lines
> 
>
> Key: VELOCITY-950
> URL: https://issues.apache.org/jira/browse/VELOCITY-950
> Project: Velocity
>  Issue Type: Wish
>  Components: Engine
>Reporter: Ivan Galkin
>Priority: Major
>
> I need to convert text from Word to PDF using "if" (or others) construction 
> of Velocity. I need to get rid of empty lines.
> Example:
> In Word it looks like: 
> «#if(xxx == "true)»1«#end»
> «#if(yyy == "true)»1«#end»
> «#if(zzz == "true)»1«#end»
> If yyy == false, xxx and zzz are true in PDF we will get:
> 1
>  
> 1
> But I need get it without an empty line somehow:
> 1
> 1
> Is it possible to do it with such functionality?



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-191) Upgrading commons-validator past v1.4.1 and still trying to use javascript validation causes NullPointerException

[Christopher Schultz (Jira)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-191.
--
Fix Version/s: 2.x
 Assignee: Christopher Schultz
   Resolution: Fixed

Fixed with git commit 394787eb20ea8a5bf437710fd47ed902943574cd

> Upgrading commons-validator past v1.4.1 and still trying to use javascript 
> validation causes NullPointerException
> -
>
> Key: VELTOOLS-191
> URL: https://issues.apache.org/jira/browse/VELTOOLS-191
> Project: Velocity Tools
>  Issue Type: Bug
>  Components: VelocityStruts
>Affects Versions: 2.0
>    Reporter: Christopher Schultz
>    Assignee: Christopher Schultz
>Priority: Minor
> Fix For: 2.x
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-191) Upgrading commons-validator past v1.4.1 and still trying to use javascript validation causes NullPointerException

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435018#comment-17435018
 ] 

Christopher Schultz commented on VELTOOLS-191:
--

Exception stack trace:

{{org.apache.velocity.exception.MethodInvocationException: Invocation of method 
'getDynamicJavascript' in class org.apache.velocity.tools.struts.ValidatorTool 
threw exception java.lang.NullPointer}}
{{Exception at [template].vm[line Y, column X]}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:223)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)}}
{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)}}
{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
{{ at org.apache.velocity.Template.merge(Template.java:356)}}
{{ at org.apache.velocity.Template.merge(Template.java:260)}}
{{ at 
org.apache.velocity.tools.view.VelocityLayoutServlet.mergeTemplate(VelocityLayoutServlet.java:206)}}
{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doRequest(VelocityViewServlet.java:220)}}
{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doGet(VelocityViewServlet.java:182)}}
{{ at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)}}
{{ at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)}}{{[...]}}{{Caused 
by: java.lang.NullPointerException
 at 
org.apache.velocity.tools.struts.ValidatorTool.createMethods(ValidatorTool.java:722)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:505)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getJavascript(ValidatorTool.java:470)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:449)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:410)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:142)
 at 
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:539)
 at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:198)
 ... 117 more}}

One could argue that javascript validation should not be used past 
commons-validator v1.4.1, but the fact remains that commons-validator claims 
that v1.5 (the next version up from v1.4.1) has "NO BREAKING CHANGES" when in 
fact an upgrade to just the library in your application may result in NPEs any 
time you are trying to display a form. (Oops).

> Upgrading commons-validator past v1.4.1 and still trying to use javascript 
> validation causes NullPointerException
> -
>
> Key: VELTOOLS-191
> URL: https://issues.apache.org/jira/browse/VELTOOLS-191
> Project: Velocity Tools
>  Issue Type: Bug
>  Components: VelocityStruts
>Affects Versions: 2.0
>Reporter: Christopher Schultz
>Priority: Minor
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Comment Edited] (VELTOOLS-191) Upgrading commons-validator past v1.4.1 and still trying to use javascript validation causes NullPointerException

[Christopher Schultz (Jira)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435018#comment-17435018
 ] 

Christopher Schultz edited comment on VELTOOLS-191 at 10/27/21, 7:14 PM:
-

Exception stack trace:

{{org.apache.velocity.exception.MethodInvocationException: Invocation of method 
'getDynamicJavascript' in class org.apache.velocity.tools.struts.ValidatorTool 
threw exception java.lang.NullPointer}}
 {{Exception at [template].vm[line Y, column X]}}
 \{{ at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:223)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)}}
 \{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
 \{{ at org.apache.velocity.Template.merge(Template.java:356)}}
 \{{ at org.apache.velocity.Template.merge(Template.java:260)}}
 \{{ at 
org.apache.velocity.tools.view.VelocityLayoutServlet.mergeTemplate(VelocityLayoutServlet.java:206)}}
 \{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doRequest(VelocityViewServlet.java:220)}}
 \{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doGet(VelocityViewServlet.java:182)}}
 \{{ at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)}}
 \{{ at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)}}{{[...]}}{{Caused 
by: java.lang.NullPointerException
 at 
org.apache.velocity.tools.struts.ValidatorTool.createMethods(ValidatorTool.java:722)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:505)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getJavascript(ValidatorTool.java:470)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:449)
 at 
org.apache.velocity.tools.struts.ValidatorTool.getDynamicJavascript(ValidatorTool.java:410)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.apache.velocity.runtime.parser.node.PropertyExecutor.execute(PropertyExecutor.java:142)
 at 
org.apache.velocity.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:539)
 at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:198)
 ... 117 more}}

 

One could argue that javascript validation should not be used past 
commons-validator v1.4.1, but the fact remains that commons-validator claims 
that v1.5 (the next version up from v1.4.1) has "NO BREAKING CHANGES" when in 
fact an upgrade to just the library in your application may result in NPEs any 
time you are trying to display a form. (Oops).


was (Author: ch...@christopherschultz.net):
Exception stack trace:

{{org.apache.velocity.exception.MethodInvocationException: Invocation of method 
'getDynamicJavascript' in class org.apache.velocity.tools.struts.ValidatorTool 
threw exception java.lang.NullPointer}}
{{Exception at [template].vm[line Y, column X]}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTIdentifier.execute(ASTIdentifier.java:223)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:369)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)}}
{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
{{ at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:106)}}
{{ at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)}}
{{ at org.apache.velocity.Template.merge(Template.java:356)}}
{{ at org.apache.velocity.Template.merge(Template.java:260)}}
{{ at 
org.apache.velocity.tools.view.VelocityLayoutServlet.mergeTemplate(VelocityLayoutServlet.java:206)}}
{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doRequest(VelocityViewServlet.java:220)}}
{{ at 
org.apache.velocity.tools.view.VelocityViewServlet.doGet(VelocityViewServlet.java:182)}}
{{ at javax.servlet.http.HttpServlet.service(HttpServlet.java:655)}}
{{ at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:764)}}{{[...]}}{{Caused 
by: java.lang.NullPointerException
 at 
org.apache.velocity.tools.struts.ValidatorTool.createMethods(ValidatorToo

[jira] [Created] (VELTOOLS-191) Upgrading commons-validator past v1.4.1 and still trying to use javascript validation causes NullPointerException

[Christopher Schultz (Jira)]

Christopher Schultz created VELTOOLS-191:


 Summary: Upgrading commons-validator past v1.4.1 and still trying 
to use javascript validation causes NullPointerException
 Key: VELTOOLS-191
 URL: https://issues.apache.org/jira/browse/VELTOOLS-191
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
Reporter: Christopher Schultz






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: 1.7.x backport for [SecureUberspector should block methods on ClassLoader and subclasses]

[Christopher Schultz]

Claude,

On 3/23/21 03:06, Claude Brisson wrote:

If I go to this page:

     https://wiki.shibboleth.net/confluence/display/OS30/Home

the first thing I see is the not at the top which states:

     "The OpenSAML 3 software has reached its End of Life and is no 
longer supported. This space is available for historical purposes only."


So why bother patching Velocity 1.7 since the transitive dependency you 
refer to has reached end of life?


Amusingly enough, "OpenSAML 3.0 is EOL" but "OpenSAML 4.0 isn't released 
yet".


The people at OpenSAML seem not to have their stuff together.

-chris


On 2021-03-23 05 h 02, Cesar Hernandez wrote:

Hi all,

I opened https://issues.apache.org/jira/browse/VELOCITY-941 along with 
the

Pull Request  https://github.com/apache/velocity-engine/pull/21 to
accomplish the backport of the patch applied to master via
https://issues.apache.org/jira/browse/VELOCITY-931
Hope the backport makes sense since there is still transitive 
dependencies

from the 1.7 release [1]

[1]
https://issues.apache.org/jira/browse/WSS-683
https://github.com/apache/velocity-engine/pull/16#issuecomment-799180202


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Limiting VelocityLayoutServlet buffer size

[Christopher Schultz]

Nathan,

On 12/16/20 12:43, Nathan Bubna wrote:

I don't honestly know much about JDK licensing, so i'll leave that to
you or others. In general, i think the overhead from StringWriter is
probably pretty minimal.

Before worrying about it, I'd want to see some profiling that showed
it was a problem.
I did a quick test of StringBuffer vs StringBuilder, trying to remove 
everything I could from the test that could affect it other than the 
obvious slight difference in synchronization strategy between the two.


In Java 8, StringBuilder wins by a factor of 10. In Java 15, it's a 
factor of ~20.


Feel free to check my methodology. I'm attaching the source to my test 
at the end of this post.


I'm assuming that StringWriter just being a thin wrapper around 
StringBuffer is going to exhibit similar performance. The question is 
whether or not it will make a difference when using a StringWriter 
versus a proposed StringBuilderWriter when the thing that's likely to 
take the most time is the many re-sizes of the internal char[] array 
that both use.


I can build a new StringBuilderWriter and benchmark the two against each 
other. (Actually, commons-io has a StringBuilderWriter since 2015, so I 
can borrow that one for a performance-test).


Perhaps starting with a larger-than-default buffer for those will also 
help. (The default size of a StringWriter -- which is what 
VelocityLayoutServlet uses - is a mere 16 characters). I find it 
unlikely that such a small buffer would be practical for most Velocity 
workloads. Maybe we can improve performance a bit by specifying a larger 
default buffer/builder size to avoid some of the initial buffer-resizes 
that will inevitably occur.



Our dev resources these days are limited and things are pretty
stable, so i'm wary of taking on optimizations that increase our
complexity.


Understood.

Thanks,
-chris

=== CUT ===
public class StringBuXtest {
public static void main(String[] args) {
int size = 10;
int iterations = 5000;
StringBuffer buffer = new StringBuffer(size);
StringBuilder builder = new StringBuilder(size);

// Warm up
exercise(buffer, 10, size);
exercise(builder, 10, size);
exercise(buffer, 10, size);
exercise(builder, 10, size);
exercise(buffer, 10, size);
exercise(builder, 10, size);

long elapsed;

elapsed = System.currentTimeMillis();
exercise(buffer, iterations, size);
elapsed = System.currentTimeMillis() - elapsed;

System.out.println("StringBuffer: " + iterations + " iterations 
in " + elapsed + "ms");


elapsed = System.currentTimeMillis();
exercise(builder, iterations, size);
elapsed = System.currentTimeMillis() - elapsed;

System.out.println("StringBuilder: " + iterations + " 
iterations in " + elapsed + "ms");

}

public static void exercise(StringBuilder sb, int iterations, int 
size) {

for(int i=0; ipublic static void exercise(StringBuffer sb, int iterations, int 
size) {

    for(int i=0; i
On Mon, Dec 14, 2020 at 8:38 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Nathan,

On 12/14/20 11:15, Nathan Bubna wrote:

I'm pretty sure we don't have a setting like that.


Yep, I just got into the code and was writing a patch for it:

L265
  protected void mergeTemplate(Template template, Context context,
   HttpServletResponse response)
  throws IOException
  {
  //
  // this section is based on Tim Colson's "two pass render"
  //
  // Render the screen content
  StringWriter sw = new StringWriter();
  template.merge(context, sw);
  // Add the resulting content to the context
  context.put(KEY_SCREEN_CONTENT, sw.toString());


I have a LimitedStringWriter class that can be swapped-in for
StringWriter, but I'm having trouble building the JAR files due to an
unrelated build issue. I'll post about that separately.

If I'm going to implement a limited StringWriter class, I'm wondering if
we shouldn't also take the opportunity to improve performance by using a
StringBuilder internally instead of a StringBuffer (which is what
java.io.StringWriter uses internally). Since this isn't expected to be
multi-threaded, the overhead of synchronization on StringWriter's
StringBuffer can be avoided. That would essentially require writing a
complete clone of StringWriter, which, while not complicated, might
possibly violate JDK licensing since I have recently read the code for
StringWriter in order to build the subclass. :(

I didn't see anything in commons-lang or similar existing dependencies
that might fit the billing, so I have left it alone for now.

-chris


On Mon, Dec 14, 2020 at 8:01 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

We re

[tools] Errors running 2.0.x branch unit tests in trunk

[Christopher Schultz]

All,

I realize that 2.0 is a little long in the tooth, but I haven't yet 
moved to 3.0 (I still need Struts support) and so I'm working with that 
for the time being.


$ svn checkout 
http://svn.apache.org/repos/asf/velocity/tools/branches/2.0.x 
velocity-tools-2.0.x


$ cd velocity-tools-2.0.x

$ mvn package

This generates a lot of errors running the unit tests. Looking at 
README.txt says to use ant. Okay:


$ ant
   [...]
do-http-m2-download:
  [get] Getting: 
http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.2/commons-collections-3.2.jar

   [...]
  [get] Can't get 
http://www.ibiblio.org/maven2/commons-collections/commons-collections/3.2/commons-collections-3.2.jar 
to velocity-tools-2.0.x/lib/commons-collections-3.2.jar


BUILD FAILED

Okay, this is a bit old. Let's adjust some version numbers and the 
primary download base URL.


And a bunch of ant properties and dependencies. In order to get "ant" to 
build successfully, I needed to apply this patch:


$ svn diff
Index: build.properties
===
--- build.properties(revision 1884424)
+++ build.properties(working copy)
@@ -121,8 +121,10 @@
 # We download directly from the ibiblio maven repository
 #
 #repo.m1.url=http://www.ibiblio.org/maven
-repo.m1.url=http://mirrors.ibiblio.org/pub/mirrors/maven2
-repo.m2.url=http://www.ibiblio.org/maven2
+#repo.m1.url=http://mirrors.ibiblio.org/pub/mirrors/maven2
+#repo.m2.url=http://www.ibiblio.org/maven2
+repo.m1.url=https://repo1.maven.org/maven2
+repo.m2.url=https://repo1.maven.org/maven2

 # Skip or force downloading of dependencies
 skip.jar.loading= false
@@ -131,22 +133,22 @@
 # Jars to be downloaded for compilation
 #
 jar.antlr.version= 2.7.2
-jar.commons-beanutils.version= 1.7.0
+jar.commons-beanutils.version= 1.9.4
 jar.commons-chain.version= 1.1
-jar.commons-collections.version= 3.2
-jar.commons-digester.version= 1.8
-jar.commons-lang.version= 2.2
-jar.commons-logging.version= 1.1
-jar.commons-validator.version= 1.3.1
+jar.commons-collections.version= 3.2.2
+jar.commons-digester.version= 1.8.1
+jar.commons-lang.version= 2.6
+jar.commons-logging.version= 1.1.1
+jar.commons-validator.version= 1.4.1
 jar.dom4j.version= 1.6.1
-jar.jaxen.version= 1.1-beta-6
+jar.jaxen.version= 1.1
 jar.oro.version= 2.0.8
 jar.servletapi.version= 2.3
 jar.sslext.version = 1.2-0
-jar.struts-core.version = 1.3.8
-jar.struts-taglib.version = 1.3.8
-jar.struts-tiles.version = 1.3.8
-jar.velocity.version= 1.6.4
+jar.struts-core.version = 1.3.10
+jar.struts-taglib.version = 1.3.10
+jar.struts-tiles.version = 1.3.10
+jar.velocity.version= 1.7

 # Jars to be downloaded for building documentation
 #
Index: build.xml
===
--- build.xml   (revision 1884424)
+++ build.xml   (working copy)
@@ -453,6 +453,7 @@
   
   
+
 
   

Index: download.xml
===
--- download.xml(revision 1884424)
+++ download.xml(working copy)
@@ -149,6 +149,7 @@

   
 
+
 
 
 src="${repo.m1.url}/${download.path}/${download.artifactId}-${download.version}.jar"


Does all of that look okay?

I tried checking-out the "2.x" branch, but literally nothing works in 
there. It looks like that was something Claude tried and then gave up on.


There are also some test failures.

Any objections to me committing the above changes to the old branch? 
Then maybe investigating and fixing the unit test errors?


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Limiting VelocityLayoutServlet buffer size

[Christopher Schultz]

Nathan,

On 12/14/20 11:15, Nathan Bubna wrote:

I'm pretty sure we don't have a setting like that.


Yep, I just got into the code and was writing a patch for it:

L265
protected void mergeTemplate(Template template, Context context,
 HttpServletResponse response)
throws IOException
{
//
// this section is based on Tim Colson's "two pass render"
//
// Render the screen content
StringWriter sw = new StringWriter();
template.merge(context, sw);
// Add the resulting content to the context
context.put(KEY_SCREEN_CONTENT, sw.toString());


I have a LimitedStringWriter class that can be swapped-in for 
StringWriter, but I'm having trouble building the JAR files due to an 
unrelated build issue. I'll post about that separately.


If I'm going to implement a limited StringWriter class, I'm wondering if 
we shouldn't also take the opportunity to improve performance by using a 
StringBuilder internally instead of a StringBuffer (which is what 
java.io.StringWriter uses internally). Since this isn't expected to be 
multi-threaded, the overhead of synchronization on StringWriter's 
StringBuffer can be avoided. That would essentially require writing a 
complete clone of StringWriter, which, while not complicated, might 
possibly violate JDK licensing since I have recently read the code for 
StringWriter in order to build the subclass. :(


I didn't see anything in commons-lang or similar existing dependencies 
that might fit the billing, so I have left it alone for now.


-chris


On Mon, Dec 14, 2020 at 8:01 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

We recently suffered an OOME in production because we had a huge SQL
query return a log of data which, in turn, generated even more HTML
output for a particular screen.

We got an OOME with ASTNode.render trying to call StringWriter.write
(which calls StringBuffer's auto-re-sizing) because the output string
simply grew too much.

We are of course fixing the SQL query to make sure we limit the amount
of data that can come back, but we'd also like to make sure that
Velocity doesn't trigger an OOME like this if possible.

Is there a setting for limiting the output buffer size? I haven't yet
found one in the documentation, so I'm starting to look in the code.

Thanks,
-chris

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Limiting VelocityLayoutServlet buffer size

[Christopher Schultz]

All,

We recently suffered an OOME in production because we had a huge SQL 
query return a log of data which, in turn, generated even more HTML 
output for a particular screen.


We got an OOME with ASTNode.render trying to call StringWriter.write 
(which calls StringBuffer's auto-re-sizing) because the output string 
simply grew too much.


We are of course fixing the SQL query to make sure we limit the amount 
of data that can come back, but we'd also like to make sure that 
Velocity doesn't trigger an OOME like this if possible.


Is there a setting for limiting the output buffer size? I haven't yet 
found one in the documentation, so I'm starting to look in the code.


Thanks,
-chris

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [OT] Problems with commons-beanutils-1.9.4

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Claude,

On 2/7/20 02:09, Claude Brisson wrote:
> On 20-02-06 16 h 15, Christopher Schultz wrote:
>
>> 3.0 completely dropped support for Struts, which is a requirement
>> for me, so I don't have any current stake in velocity-tools 3.0.
>> I'm happy to do the work (delete 4 lines of code; document;
>> commit) but I won't have anything to test it with other than the
>> existing unit tests.
>
> Does it also mean that you are stuck with Velocity 1.7?

Yes.

> I'm pretty sure that the struts tools could be easily upgraded to
> work with tools 3.x, but they should probably be hosted by the
> struts project...

That would be nice, but I don't know if there is any appetite over
there to take-on this project.

I might be able to find time to maintain it myself, but I'd want to
make sure at least a few other people in that community cared enough
to keep it going, too.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5s4GIACgkQHPApP6U8
pFhsmw/9ENxOVTd93a6Mt2353ITH9FVrFWdmGGrPxtL/HKL8CNKoG+Xy1HCoczOW
vVpkX2aCu4MNllKO6I+zV6OE6k6aKFsnpgbycPHkodL1qmk9U9lNlIoGLhcYRvrV
ACqn+Yety3J4Tem4gIbPTCmpAtLvyEquJqY11yLDvDdg3De4uVMuyqQAccr9s1v7
8+n5QwqShXd+TTmj+bFWaPrig9uuNy7h3R6tmxNdLmqrk2fs4trfFGbHbcUS5lwH
ycamhSFHl7OHXc2/4M3tAYMt4pV3fKyvBsni0/l1VnXmQyu5o6XqdZHPstGaOAeL
xRr2x4GtaCItKEr3jo+Gwz8Z8jZhBiCsD1TbbPQBPXcmK71GAXY7+i9XrpwuvMEW
KRzgijCpXE3IRkcRt9bGTFMRW6SDyTcZkCH9eg+c/m6WTD1tf4FSZGSrpoqIUA/0
PXyc2gtw3ez0M8qTA3FDiKIu9T7vMLeBC/SoSudjwWwJFgu5POb5bi74PpqIasFe
xWBoelzd2qcVvgo4F1hctZ2JQdL+jkAzHY5la3DjVE8L5MXX75fUUsJezRhFhCKQ
2BtzjeijH48cAFjlJi/1PGsN9TF/aZnGocYlazHIjvAz8sJbRjc2f+FPhRQzNjBW
sStpMTeQ2NL3KhYh6jX3y99+5Cxf4+Nx23d7RKRi4TNVL/BpmeE=
=QNg+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Problems with commons-beanutils-1.9.4

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nathan,

(Apologies for the cross-post, but this is a very dev-y response.
After this message in the thread, I will reply only on the dev@ list).

On 2/5/20 1:09 PM, Nathan Bubna wrote:
> Thanks for drilling into that, Chris! I was reading, but have no
> time to help with such things right now. I imagine the beanutils
> folks made that change as a security fix. Probably time for us to
> deprecate/kill the setClass option, if it's unreliable. Any chance
> you're up for that?

Sure. It's easy to do; just drop the method completely.

I might argue for a transitional period where we change setClass() to
either issue a WARN log message or even throw an exception, but anyone
upgrading to commons-beanutils-1.9.4 or later will find that it stops
working and that method never ever gets called, so it's kind of wasted
effort.

Anyone upgrading velocity-tools will likely be upgrading
commons-beanutils as well (and vice-versa), so the only people who
need the nudge to change their configurations are those who aren't
likely to upgrade. Again, wasted effort.

So I think just removing the setClass(Class) method is the proper
course of action.

I suspect there is no reason for a 2.0.1 release, so this would be a
change only in 3.0?

3.0 completely dropped support for Struts, which is a requirement for
me, so I don't have any current stake in velocity-tools 3.0. I'm happy
to do the work (delete 4 lines of code; document; commit) but I won't
have anything to test it with other than the existing unit tests.

- -chris

> On Wed, Feb 5, 2020 at 9:55 AM Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> All,
> 
> This may be an uncommon configuration, but I just upgraded from 
> velocity-tools-2.0 with commons-beanutils-1.9.3 to 
> commons-beanutils-1.9.4 and all my stuff broke.
> 
> I spent a few hours tracking it down and I happened to have my
> toolbox configured like this:
> 
>    class="org.apache.velocity.tools.generic.AlternatorTool" /> [...] 
>  
> 
> I was getting a message on webapp start that looked like this:
> 
> FactoryConfiguration from 4 sources  with 2 toolboxes: Toolbox
> 'application' with 1 properties [scope -auto-> application; ] and
> 12 tools: Tool 'null' => null
> 
> and some other weird things like:
> 
> Tool 'dateFormat' => null with 1 properties [key -auto->
> dateFormat; ]
> 
> The problem is that I was using the "class" attribute in my XML
> config instead of "classname".
> 
> velocity-tools uses commons-digester, which uses commons-beanutils
> to:
> 
> 1. Create an instance of ToolConfiguration for each  2. Set
> the properties on ToolConfiguration for each 
> 
> Then velocity-tools tries to instantiate the class you specify, put
> it into the toolbox, etc. The problem is with step #2 above.
> 
> ToolConfiguration has two relevant setters, here:
> 
> public void setClass(Class); public void setClassname(String);
> 
> Before commons-beanutils-1.9.4, setting the "class" attribute in
> the XML would:
> 
> 1. Find the "class" property on ToolConfiguration 2. Use
> Class.forName() to get an instance of java.lang.Class representing
> whatever class you wanted to use 3. Call
> ToolConfiguration.setClass(Class) with that instance of 
> java.lang.Class.
> 
> With commons-beanutils-1.9.4, that process fails at one point or 
> another because commons-beanutils is no longer willing to
> instantiate objects of type java.lang.Class (or no longer willing
> to assign properties of java.lang.Class, it doesn't really
> matter).
> 
> But because ToolConfiguration is designed to accept class names and
> do it's own object instantiation, you can side-step the "problem" 
> introduced by commons-beanutils-1.9.4 by simply using the other 
> attribute: classname
> 
> When you use "classname", commons-beanutils will:
> 
> 1. Find the "classname" property on ToolConfiguration 2. Call
> ToolConfiguration.setClassname(String) with the String value 
> obtained from the XML attribute
> 
> ... and you are good to go.
> 
> I hope nobody else gets bitten by this, but in case you do, there
> is a simple solution.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: user-unsubscr...@velocity.apache.org
>> For additional commands, e-mail: user-h...@velocity.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl48LZYACgkQHPApP6U8
pFh0OBAAnFBWGITPXf8wc3nTgRZnvUknwNqgems6vmCELUbKeQWIUDfrNNuW5n73
ZDs2mw

Re: Error starting Velocity 1.7 + Tools 2.0 after upgrading commons-beanutils

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 2/4/20 3:33 PM, Christopher Schultz wrote:
> I just upgraded an application from commons-beanutils-1.9.3 to 
> commons-beanutils-1.9.4 that is using Velocity 1.7 and Tools 2.0
> and I'm getting this error on startup:
> 
> Caused by: org.apache.velocity.tools.config.NullKeyException: Key
> is null for tool whose class is 'null' at 
> org.apache.velocity.tools.config.ToolConfiguration.validate(ToolConfig
ur
>
> 
ation.java:348)

I think I've figured this out.

The ToolConfiguration class has two sets of properties:

  public void setClass(Class);  // Write-only
  public void getClassname(String); // Write
  public String getClassname(); // Read

In my tools.xml, I had the following XML:


  

[...]
  


In commons-beanutils up through 1.9.3, it would happily convert the
"class" XML attribute into an instance of java.lang.Class representing
the Class named in the string, and call setClass(Class) which ... just
sets the class name:

public void setClass(Class clazz)
{
setClassname(clazz.getName());
}

In commons-beanutils-1.9.4, it doesn't want to allow you to set a
Class property anymore. I didn't follow all the code in
commons-beanutils all the way down, but I was able to finally see that
it wasn't finding "class" as a settable property on the
ToolConfiguration class for whatever reason (probably a blacklist of
property names).

The obvious solution is just to use the "classname" attribute instead
of the "class" attribute and everything is fine:


  

[...]
  


And now I get what I'm expecting:

FactoryConfiguration from 4 sources  with 2 toolboxes:
 Toolbox 'application' with 1 properties [scope -auto-> application; ]
and 15 tools:
  Tool 'alternator' =>
org.apache.velocity.tools.generic.AlternatorTool with 1 properties
[classname -auto-> org.apache.velocity.tools.generic.AlternatorTool; ]
  [...]

I hope that helps someone else with this same problem, because I was
seriously worried about what I was going to do, here :)

I'm going to post a message to the users@ list summarizing this just
in case it happens to anyone else.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl46/18ACgkQHPApP6U8
pFggDBAAswWW93jo2wV895n/K6uGIlYIQLojgsvUs7/OMUOy2uElaQvlTQqBdLwJ
JVue4eEDqbVSKXMPW73Jwisq44YvltiPcNFnQCxJzUKnVZDborvmgLgv3puIeD+y
yx16iBL1QUQ5z0aSE7K9TxhLpWpgp5N0/CmQonbGzrIkAnbCimZnuxrUrMKjQ2Ip
/oUCrdKKbypjrSbqVwR1K24HoGcA9S+pPPTAaWUEbrgFq5GpbzWFhTwOVinBWa87
8nWSqbE2ilIjPKvWH2IvLCTB59raPAywYp3RBVI2TUaBWWfO94LFuhdI3AgmRgde
p42I0ms7Q4fbAAUraHkKqKjaL2F39UcnMXhskqqHrjf08B6YFecto01eOhWuySDG
/L22MTp6Hy7W15rcPS5mewU2YaM5p/PXu3NzyiQGqArQ81BaZq31Wwz9kagNneLu
0PNVQWjOeQ/k0mtSuStk/Sc2uYIAhsFWU3B6BnrapomrL474g+AN8rFpFqH6lsOo
RQHDBnbcXAx2hOq7VjEUj2HL2PqIYZIsD9c+JZ6k2FdQDeRr0702atHHfgDE9VVo
QAaC148exVl3SHgsuLQXVViQSMWfuPqWLiu6eThRnox3HEs/VDqGJEi+DQ5icmP6
dvNlmfdowwT1jrAdhPAbuLgYS18zPofOaLBOUbMV9dCQePf+oVk=
=8z81
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Error starting Velocity 1.7 + Tools 2.0 after upgrading commons-beanutils

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 2/4/20 3:33 PM, Christopher Schultz wrote:
> All,
> 
> I just upgraded an application from commons-beanutils-1.9.3 to 
> commons-beanutils-1.9.4 that is using Velocity 1.7 and Tools 2.0
> and I'm getting this error on startup:
> 
> javax.servlet.ServletException: Servlet.init() for servlet
> [velocity] threw exception [...] Caused by:
> org.apache.velocity.tools.config.NullKeyException: Key is null for
> tool whose class is 'null' at 
> org.apache.velocity.tools.config.ToolConfiguration.validate(ToolConfig
ur
>
> 
ation.java:348)
> at 
> org.apache.velocity.tools.config.CompoundConfiguration.validate(Compou
nd
>
> 
Configuration.java:115)
> at 
> org.apache.velocity.tools.config.ToolboxConfiguration.validate(Toolbox
Co
>
> 
nfiguration.java:108)
> at 
> org.apache.velocity.tools.config.CompoundConfiguration.validate(Compou
nd
>
> 
Configuration.java:115)
> at 
> org.apache.velocity.tools.config.FactoryConfiguration.validate(Factory
Co
>
> 
nfiguration.java:232)
> at 
> org.apache.velocity.tools.ToolboxFactory.configure(ToolboxFactory.java
:8
>
> 
0)
> at 
> org.apache.velocity.tools.ToolManager.configure(ToolManager.java:90)
>
> 
at
> org.apache.velocity.tools.view.ViewToolManager.configure(ViewToolManag
er
>
> 
.java:222)
> at 
> org.apache.velocity.tools.view.VelocityView.configure(VelocityView.jav
a:
>
> 
508)
> at 
> org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:313
)
>
> 
at
> org.apache.velocity.tools.view.VelocityView.(VelocityView.java:2
13
>
> 
)
> at 
> org.apache.velocity.tools.view.ServletUtils.createView(ServletUtils.ja
va
>
> 
:156)
> at 
> org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUti
ls
>
> 
.java:142)
> at 
> org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUti
ls
>
> 
.java:104)
> at 
> org.apache.velocity.tools.view.VelocityViewServlet.getVelocityView(Vel
oc
>
> 
ityViewServlet.java:155)
> at 
> org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewSe
rv
>
> 
let.java:122)
> at 
> org.apache.velocity.tools.view.VelocityLayoutServlet.init(VelocityLayo
ut
>
> 
Servlet.java:133)
> at 
> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.j
av
>
> 
a:1142)
> ... 89 more
> 
> 
> I don't believe I've changed my tools.xml file for a long time
> (svn says no). The changelog for commons-beanutils says their
> change is to fix CVE-2014-0114 / CVE-2019-10086 which has to do
> with whether or not a "class" may be specified under certain
> conditions.
> 
> I haven't (yet) looked at the code, but is it possible that this 
> upgrade has broken Velocity Tools 2.0? I realize this is a
> somewhat older release; upgrading will take some time, patching is
> the preferred source of action at the moment.

On startup, I get this message before Bad Things happen:

2020-02-05 10:58:10,737 [main] DEBUG org.apache.velocity.generic-
Configuring factory with:
FactoryConfiguration from 4 sources  with 2 toolboxes:
 Toolbox 'application' with 1 properties [scope -auto-> application; ]
and 12 tools:
  Tool 'null' => null
  Tool 'JSONUtil' => null with 1 properties [key -auto-> JSONUtil; ]
  Tool 'dateFormat' => null with 1 properties [key -auto-> dateFormat; ]
  Tool 'escape' => null with 1 properties [key -auto-> escape; ]
  Tool 'floatMath' => null with 1 properties [key -auto-> floatMath; ]
  Tool 'list' => null with 1 properties [key -auto-> list; ]
  Tool 'modernEscape' => null with 1 properties [key -auto->
modernEscape; ]
  Tool 'resource' => null with 1 properties [key -auto-> resource; ]

So two things are happening, here:

1. Any tool without an explicit "key" is being set to key=null

2. No class names are being loaded AT ALL

With commons-beanutils-1.9.3, the output is a little different:

2020-02-05 15:41:49,901 [localhost-startStop-1] DEBUG
org.apache.velocity.generic- Configuring factory with:
FactoryConfiguration from 4 sources  with 2 toolboxes:
 Toolbox 'application' with 1 properties [scope -auto-> application; ]
and 14 tools:
  Tool 'JSONUtil' => org.noggit.JSONUtil with 1 properties [key
- -auto-> JSONUtil; ]
  Tool 'alternator' => org.apache.velocity.tools.generic.AlternatorTool
  Tool 'class' => org.apache.velocity.tools.generic.ClassTool
  Tool 'dateFormat' => org.apache.velocity.tools.generic.DateTool with
1 properties [key -auto-> dateFormat; ]
  Tool 'escape' => org.apache.velocity.tools.generic.EscapeTool with 1
properties [key -auto-> escape; ]
  Tool 'floatMath' => org.apache.velocity.tools.generic.MathTool with
1 properties [key -auto-> floatMath; ]
  Tool 'list'

Error starting Velocity 1.7 + Tools 2.0 after upgrading commons-beanutils

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I just upgraded an application from commons-beanutils-1.9.3 to
commons-beanutils-1.9.4 that is using Velocity 1.7 and Tools 2.0 and
I'm getting this error on startup:

javax.servlet.ServletException: Servlet.init() for servlet [velocity]
threw exception
[...]
Caused by: org.apache.velocity.tools.config.NullKeyException: Key is
null for tool whose class is 'null'
at
org.apache.velocity.tools.config.ToolConfiguration.validate(ToolConfigur
ation.java:348)
at
org.apache.velocity.tools.config.CompoundConfiguration.validate(Compound
Configuration.java:115)
at
org.apache.velocity.tools.config.ToolboxConfiguration.validate(ToolboxCo
nfiguration.java:108)
at
org.apache.velocity.tools.config.CompoundConfiguration.validate(Compound
Configuration.java:115)
at
org.apache.velocity.tools.config.FactoryConfiguration.validate(FactoryCo
nfiguration.java:232)
at
org.apache.velocity.tools.ToolboxFactory.configure(ToolboxFactory.java:8
0)
at
org.apache.velocity.tools.ToolManager.configure(ToolManager.java:90)
at
org.apache.velocity.tools.view.ViewToolManager.configure(ViewToolManager
.java:222)
at
org.apache.velocity.tools.view.VelocityView.configure(VelocityView.java:
508)
at
org.apache.velocity.tools.view.VelocityView.init(VelocityView.java:313)
at
org.apache.velocity.tools.view.VelocityView.(VelocityView.java:213
)
at
org.apache.velocity.tools.view.ServletUtils.createView(ServletUtils.java
:156)
at
org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils
.java:142)
at
org.apache.velocity.tools.view.ServletUtils.getVelocityView(ServletUtils
.java:104)
at
org.apache.velocity.tools.view.VelocityViewServlet.getVelocityView(Veloc
ityViewServlet.java:155)
at
org.apache.velocity.tools.view.VelocityViewServlet.init(VelocityViewServ
let.java:122)
at
org.apache.velocity.tools.view.VelocityLayoutServlet.init(VelocityLayout
Servlet.java:133)
at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.jav
a:1142)
... 89 more


I don't believe I've changed my tools.xml file for a long time (svn
says no). The changelog for commons-beanutils says their change is to
fix CVE-2014-0114 / CVE-2019-10086 which has to do with whether or not
a "class" may be specified under certain conditions.

I haven't (yet) looked at the code, but is it possible that this
upgrade has broken Velocity Tools 2.0? I realize this is a somewhat
older release; upgrading will take some time, patching is the
preferred source of action at the moment.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl451RYACgkQHPApP6U8
pFh8bg/+IvYBoK+cQCp+Zxw8obleefonlHsJOjtCK/DIkvC1hbtLX27xURkmCQ3r
pOI9lsEv3L1GYAN2GF090FWjDj3QFiE2m5HD9pHtscpCKoDqBXVgE/JanHYiQn5b
+B9v/eSYQzhlRULlPFTSBHv5W0C8yGk/RYr4eI2uIECWcPRMpVN11mkBFOsUqcrK
nP6bOlKDszS40V9JSeqmv8qELsu23q19M7nT7ECGsGxMqcy1Jc4TDECgfL9odaFZ
8u3FaVrWSXrmCRXLqBTlMtO2xoD5mq1OuRePKFShtbsUnFvG38cjbAwy5Yq++Uxl
/7d2TkBLq2yKu+vrFPjmrc5mSrH0lT1Er7GjogFI5ywiRGrLjvC0N/PZAqmqqVQl
hyY7KA5DmKyFB6eIgiKFg1PZVF69UmRyyl1aMwVYKt/R1d/B0/yvM/fuYJdPiGo3
sWn3S5alxckqug7gN9btMnayd5e4Sfrj4WhTFwS5VDc6Gj7LfMNwgsKVxh9kVCKe
PwHH/QPBNLK1ad5yI1yztS8N4nw2TXUKno8PamPxnZmMEjfzCXD7Av4O+5dqiNaH
Q+9YDDPBdwPZlJxcHklsLIl3v2AmNrijy2zIVUE6u8wUH7iNx9QHvx5PvpkMuVO5
gN2xEtYWHJgmSmt5U25oVbFjMYbVBDECkiRbdRLvyL4f9DQ32oI=
=YRv4
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Cannot build Tools from trunk

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Claude,

On 6/25/18 6:12 PM, Claude Brisson wrote:
> It's running for me under java 8. Log for the cargo section copy
> pasted below.
> 
> Is it a linux/windows cargo/jetty problem?

I think it's running under a SecurityManager and the policy isn't
allowing the "jetty.home" system property to be read.

- -chris

> [INFO] --- cargo-maven2-plugin:1.6.8:start (start-server) @ 
> velocity-tools-examples-showcase --- [INFO] [2.ContainerStartMojo]
> Resolved container artifact 
> org.codehaus.cargo:cargo-core-container-jetty:jar:1.6.8 for
> container jetty9x [INFO] You did not specify a container home nor
> any installer. CARGO will automatically download your container's
> binaries from 
> [http://repo.maven.apache.org/maven2/org/eclipse/jetty/jetty-distribut
ion/9.4.10.v20180503/jetty-distribution-9.4.10.v20180503.tar.gz].
>
>  [INFO] [talledLocalContainer] Jetty 9.4.10.v20180503 starting... 
> [INFO] [stalledLocalDeployer] Deploying WAR by creating Jetty
> context XML file in 
> [/home/claude/Projects/velocity/tools/trunk/velocity-tools-examples/ve
locity-tools-examples-showcase/target/cargo/configurations/jetty9x/webap
ps/velocity-tools-examples-showcase.xml]...
>
>  [WARNING] [talledLocalContainer] WARN  : System properties and/or
> JVM args set.  Consider using --dry-run or --exec [INFO]
> [talledLocalContainer] 2018-06-26 00:07:56.806:INFO::main: Logging
> initialized @329ms to org.eclipse.jetty.util.log.StdErrLog [INFO]
> [talledLocalContainer] 2018-06-26 00:07:56.929:INFO::main: Console
> stderr/stdout captured to 
> /home/claude/Projects/velocity/tools/trunk/velocity-tools-examples/vel
ocity-tools-examples-showcase/target/cargo/configurations/jetty9x/logs/2
018_06_25.jetty.log
>
>  [INFO] [talledLocalContainer] Jetty 9.4.10.v20180503 started on
> port [8080] [INFO] [INFO] ---
> maven-failsafe-plugin:2.22.0:integration-test (integration-test) @
> velocity-tools-examples-showcase --- [INFO] [INFO]
> --- [INFO]  T E
> S T S [INFO]
> --- [INFO]
> Running org.apache.velocity.examples.showcase.ViewToolsIT [INFO]
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
> 1.755 s - in org.apache.velocity.examples.showcase.ViewToolsIT 
> [INFO] [INFO] Results: [INFO] [INFO] Tests run: 5, Failures: 0,
> Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] ---
> cargo-maven2-plugin:1.6.8:stop (stop-server) @ 
> velocity-tools-examples-showcase --- [INFO] [talledLocalContainer]
> Jetty 9.4.10.v20180503 is stopping... [INFO] [talledLocalContainer]
> Jetty 9.4.10.v20180503 is stopped
> 
> 
> On 06/25/2018 11:02 PM, Michael Osipov wrote:
>> Folks,
>> 
>> who is able to Tools from trunk?
>> 
>> I cannot with Java 8 and 10:
>>> [INFO] --- cargo-maven2-plugin:1.6.8:start (start-server) @ 
>>> velocity-tools-examples-showcase --- [INFO]
>>> [2.ContainerStartMojo] Resolved container artifact 
>>> org.codehaus.cargo:cargo-core-container-jetty:jar:1.6.8 for
>>> container jetty9x [INFO] You did not specify a container home
>>> nor any installer. CARGO will automatically download your
>>> container's binaries from 
>>> [http://repo.maven.apache.org/maven2/org/eclipse/jetty/jetty-distrib
ution/9.4.10.v20180503/jetty-distribution-9.4.10.v20180503.tar.gz].
>>>
>>>
>>> 
[INFO] [talledLocalContainer] Jetty 9.4.10.v20180503 starting...
>>> [INFO] [stalledLocalDeployer] Deploying WAR by creating Jetty
>>> context XML file in 
>>> [D:\Entwicklung\Projekte\velocity-tools\velocity-tools-examples\velo
city-tools-examples-showcase\target\cargo\configurations\jetty9x\webapps
\velocity-tools-examples-showcase.xml]...
>>>
>>>
>>> 
[INFO] [talledLocalContainer] java.security.AccessControlException:
>>> access denied ("java.util.PropertyPermission" "jetty.home"
>>> "read") [INFO] [talledLocalContainer]   at 
>>> java.security.AccessControlContext.checkPermission(AccessControlCont
ext.java:472)
>>>
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> java.security.AccessController.checkPermission(AccessController.java
:884)
>>>
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1
294)
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> java.lang.System.getProperty(System.java:717) [INFO]
>>> [talledLocalContainer]   at 
>>> org.eclipse.jetty.start.config.CommandLineConfigSource.findJettyHome
Path(CommandLineConfigSource.java:103)
>>>
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> org.eclipse.jetty.start.config.CommandLineConfigSource.(Comman
dLineConfigSource.java:62)
>>>
>>>
>>> 
[INFO] [talledLocalContainer]   at
>>> org.eclipse.jetty.start.Main.processCommandLine(Main.java:281) 
>>> [INFO] [talledLocalContainer]   at 
>>> org.eclipse.jetty.start.Main.main(Main.java:75) [INFO]
>>> [talledLocalContainer] [INFO] 

Re: [tools] Running under a SecurityManager

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Claude,

On 3/21/18 8:25 PM, Claude Brisson wrote:
> Yes, it'd be great to soon release the tools since the engine is
> out.

Apologies for not replying sooner.

> And yes, autoconfig hasn't to be the default. Why not starting with
> an empty toolbox by default if it eases things for integrators. But
> there are two different things here: 1) *default* tools (loaded
> from tools.xml files inside each velocity-tools jar) 2) *standard*
> user toolbox configuration files

I know the world seems to be moving from "explicit configuration" to
"intelligent defaults", which is okay by me. The only problem is when
the explicit configuration is provided, those intelligent defaults
should no longer apply.

> For 1), what about a "load-default-tools" param in the descriptor?
> (As usual, we would first check init-params for the concerned
> servlet/filter and then, if not found, the context-params). It can
> be false by default for 3.0, if you guys think that that's the way
> to go. As long as we diligently document it when releasing.

I think if a user wants to explicitly-load their own file,
explicitly-loading another "defaults" file is not a problem: either
just saying "yes please load defaults" or "please load this other
file, too, which happens to be defaults".

JAR-loaded defaults (files) are okay with me.

> For 2), I'm pretty sure no standard configuration file should be
> ever checked if an explicit configuration is provided, of course
> (but, by the way, why is it problematic whenever those files aren't
> there? Oh, I see, the SecurityManager doesn't want me to read files
> that do not exist, funny but perfectly logical). Would it be
> harmful to still check for those standard locations whenever no
> explicit location is given be harmful (other than itching the
> SecurityManager)?

Yes, I think that's fine. It was only surprising to see them loaded
when I was supplying an explicit configuration.

> So if I understand correctly, we *also* need to use
> PrivilegedActions.

I think so. It will make the code much more SecurityManager-friendly.
Otherwise, I have to do ugly things like "trust my whole application"
instead of only the things that should be trusted.

> Does it boils down to wrapping system calls in 
> AccessController.doPrivileged() calls? Where and how are those
> calls authorized? Sorry, I never used the PrivilegedActions and 
> SecurityManager paradigm yet. If you have some good pointers or 
> suggestions...

Basically, things which require privileges should be changed from:

String foo = System.getProperty("bar");

to this:

String foo;

if(null != System.getSecurityManager()) {
  foo = AccessController.doPrivileged(new PrivilegedAction() {
@Override
public String run() {
return System.getProperty("bar");
}
});
} else {
  foo = System.getProperty("bar");
}

Yes, I know it's ugly and verbose but there isn't really a better way.

BTW the SecurityManager is initialized at startup so one can easily
initialize a static boolean in e.g. Velocity.java or whatever and just
consult that rather than calling System.getSecurityManager() all the tim
e.

> I don't really understand either why we're speaking of the CWD
> whereas all the VelocityView knows is the webapp root. But I may
> have missed something.

I'll have to look back at the balking done by the SecurityManager. I
believe it was looking for files with names like "./tools.xml", where
of course CWD is coming from the "./" part of the path. I think that's
probably completely unnecessary... the config files ought to come from
the JAR library itself or from the servlet context's getResource*
family of methods.

- -chris

> On 21/03/2018 22:23, Nathan Bubna wrote:
>> If we're talking 2.x, then adding a PrivilegedAction sounds
>> better. If 3.0 (which, i think needs to happen anyway, right
>> Claude?), then i'd agree with Michael. The auto config would be
>> better off as something users need to explicitly turn on, not the
>> default any longer.
>> 
>> On Wed, Mar 21, 2018 at 2:03 PM, Michael Osipov
>> <micha...@apache.org> wrote:
>> 
>>> Am 2018-03-21 um 06:17 schrieb Christopher Schultz:
>>> 
>>>> All,
>>>> 
>>>> Using velocity-tools 2.0.
>>>> 
>>>> I've been exploring what it takes to get my application
>>>> working under a SecurityManager and it seems that
>>>> o.a.v.t.view.VelocityView tries to load a few configuration
>>>> files from their default locations even when a specific
>>>> configuration file has been specified by a subclass like 
>>>> VelocityLa

[tools] Running under a SecurityManager

[Christopher Schultz]

All,

Using velocity-tools 2.0.

I've been exploring what it takes to get my application working under a
SecurityManager and it seems that o.a.v.t.view.VelocityView tries to
load a few configuration files from their default locations even when a
specific configuration file has been specified by a subclass like
VelocityLayoutServlet:

  
velocity

  com.chadis.web.servlet.VelocityLayoutServlet



  org.apache.velocity.tools
  /WEB-INF/tools.xml

  ...


What ends up happening is that VelocityView checks for the default
configuration files tools.xml and tools.properties (in the current
working directory) and so FilePermissions must be given to the whole JVM
-- because VelocityView (or ConfigurationUtils) doesn't make the attempt
in a PrivilegedAction.

I think this can be done in a more friendly way, but I'm not sure what
is best for the community.

We could add a PrivilegedAction to the mix when a SecurityManager is
present. This way, the velocity library could be granted read access to
these specific files (instead of the whole JVM). This would impact the
smallest number of users.

We could remove the attempts to load these configuration files out of
the CWD. This would probably affect the largest number of users
(although relying on the CWD to find a default configuration file is ...
bad practice).

Or we could change the way Velocity*Servlet use VelocityView so that
default configuration files are only loaded when there is no explicit
configuration file.

Thoughts?

-chris



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCE] Velocity Engine 2.0 RC9 test build available

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Claude,

On 7/17/17 7:09 AM, Claude Brisson wrote:
> A new test build of Velocity Engine 2.0 is available (RC9).
> 
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of 
> Velocity Engine 2.0 has been made, and at this time it is simply a
> "test build". We welcome any comments you may have, and will take
> all feedback into account if a quality vote is called for this
> build.
> 
> Release notes:
> 
> * 
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/re
lease-notes.html
>
> 
> 
> Distribution:
> 
> *
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
>  Maven 2 staging repository:
> 
> * 
> https://repository.apache.org/content/repositories/orgapachevelocity-1
020/
>
>  A vote regarding the quality of this test build will be initiated
> within the next couple of days.
> 
> Release Candidates changelog:
> 
> RC1: initial candidate RC2: bugfixes RC3: review SLF4J Logger names
> (instead of a single logger named "Velocity", have a hierarchy of
> loggers with a base of 'org.apache.velocity') RC4: minor fixes 
> RC5: * the default encoding is now UTF-8 (and not the platform
> default) * commons-collections is not any more a compilation
> dependency * commons-lang3 dependency is not any more shaded * the
> configuration API doesn't reference ExtProperties * the events API
> has been optimized and reviewed: all events do receive the current
> Context * there has been a few optimizations in ASTStringLiteral
> rendering RC6: mostly code cleaning and build process optimization
> ; assembly module has been dropped RC7: still a lot of core
> cleanups and reviews, plus: * new strategy for reference boolean
> evaluation * allow expressions inside [ ] : $foo[$bar + 1] RC8:
> vararg methods bugfix RC9: reenginering of the
> DataSourceResourceLoader

I should really know the answer to this question already, but I don't,
ant it's not covered in the Release Notes:

Is Velocity 2.0 backward-compatible with templates written for 1.x?
Should I be able to simply replace e.g. Velocity 1.7 with 2.0 and
expect it to work with very few changes? The changelog seems to
indicate that "most things" ought to work right away, but I thought
I'd ask.

If that's the expectation, then I'll throw 2.0 into my testing
environment immediately and see what happens.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZbRWbAAoJEBzwKT+lPKRYKtMQAJs7hVnk1KfYoQaoxbr2sJEv
RP8MsYlOjF6cpFusMDipUeC/x1LGqDLLDwDDe2yNTtu6Tsc34ds09ZY7c0pPVPwr
bPt2kj26BJI/6AGKs6X4ntJJ5dYhqppFk0VkjBl0ArB5LK6or4VTWWUyQaHrDXJB
jCv73Zisoqtkq78cC9R7iWJdcqJUbwVQSZv+Gxc2AFugnRsX+emVAHiBWOk56wS5
d5+cq8yOd/35OToQyhHebilIFYKZdPlkBkimv3YI33oMAAILsKqyl7Xo2LYj+ilT
NSgRt7bBen6mq/SmTgGC6J0hgCoORIGlJgf4gv+bLL6eNV9Jlugu/TLLqPxKzX+Z
LmJwjlCpeF/p6uKCTmrou02WzgdqcmIH0DAFuStR5rl0yPymtNjbBu5E6tz6LMb2
FoCR3aUnKVBdTPCwt0CPdV1AZ7SmlEWH/R7q0CJs7A2A7rsX0NV2hzbN8Rg/tCDd
EqHCus6ob53qZOntp7PjOGEvB4nor7DeVp/cAKNqDJ6fENp1uDue7InX4GAgyOkn
t+pRm6hrTK1aP8XY5u3g7Fe413GEDbWIXYrxFOtQK6GQmlyLbnvy7K5JAmJQ1lfH
kYYHxiw7gjzSrpPhgCHAHdmhr6d9Gty2gpWtb27h8OUIwHCQnvCWmgauqlo7Yi/A
i+COIZjnc359z4Jaiou1
=r1/H
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [jira] [Commented] (VELTOOLS-171) Upgrade to supported, secure version of Struts

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 3/9/17 6:57 PM, Claude Brisson (JIRA) wrote:
> 
> [
> https://issues.apache.org/jira/browse/VELTOOLS-171?page=com.atlassian.
jira.plugin.system.issuetabpanels:comment-tabpanel=1590
4098#comment-15904098
> ]
> 
> Claude Brisson commented on VELTOOLS-171: 
> -
> 
> I think it would be quite trivial to fix the 2.0. If someone
> submits a patch, it shouldn't be too hard for us (still ant, not
> yet maven, FYI Michael) to publish a 2.1. I agree, this discussion
> should better happen on the dev list.

I'm (still) a user of Struts 1 and likely to be a user of Struts 2 in
the future, and I need continued support for Struts in Velocity via
VelocityTools. Struts 1 support reached maturity in the past, so
there's little work to do, there. I'm not familiar enough (yet) with
Struts 2 to do a competent job supporting Struts 2 in Velocity-Tools.

As for the recent Struts-related vulnerability, Velocity-Tools uses
Struts only as a compile-time dependency (or should, anyway). It is
not critically-important that Velocity upgrade its compile-time
dependency to a recent version of Struts because the use of
Velocity-Tools does not mandate S2 or preclude an S2 upgrade by the
containing application.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYyE3/AAoJEBzwKT+lPKRYuhsP/1vCG3xi5oRyaRyxvQpJiH3F
Zz6rx4i4qEDG4ZsEf1D/gGsImtgZmYGkzXv3tKjo5fJzmzZrstagxz7GivTxlJUY
Apxx76qsmhALSDW9hHtWnPTaxgDl2rNcNiczDH7ZhdZHgQ4Z33nRyJv3Jry9qBfG
C1aYIPB0nBnI4/qurg1H8fD0jV3B5Kj5SGc1DNTxZRabUVxhAQ1BIgdsABt0GQHY
c++dD6TeOAHmtoLeur+60PMzXNDjRZntohQAGG+dQTj1ujSBS2NsI3bsHaDDjC9H
yUK8/KgRLrewb3t0I15KqIo9gZsUv0nxwA6nvxx2JP5bFhLmbRLXnEqb/Y9h6V5v
yvLX+2ALteF+O+HkG+gWTZFzbQUMyrfNhdA7C1Hy5Vk7t98to1TLB4qsxxxFDDai
SDW7sUSc3EJrlKNyYgnGWqUDJZv/QVMQKcY4DdEPmvAvUAZB3zY9UR/q9F04Zckb
DBkeaXEAkdL1NCR96MvrqNo7tzEIc9V4lupvud79vXwQgZ60CeXEovXKXCW92RXk
+Eyc2QhV4nDgstJ3y6lqjVV8LpOIz6eJ8LJE8+Be5ogrAWi66cB9ki86Q1viGkF1
o7PcSEWQPMrXg6w3+eRXYttQd/N713fcx1cSIRujYoy1Rv9j8Y3/irVZGDphA8Ef
P/mS469OmlPr3j2hnoKb
=oNSg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Velocity truth

[Christopher Schultz]

Claude,

On 1/28/17 10:15 AM, Claude Brisson wrote:
> Here's what had been specified by Nathan at the time (order is
> meaningful, and falseness seems easier to specify than truth):
> 
> $obj is null
> $obj is boolean false
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsString() (provided there is such a method)
> $obj returns empty string from getAsString() (provided there is such a
> method)
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)

I *hate* that last one. A great use-case that ran us into OOMEs for a
while until I figured out what was going on:

1. SELECT [fields] FROM table
2. Build ArrayList with e.g. User objects
3. Build a user list in HTML from a Velocity template like this:

#if($users)
  
#foreach($user in $users)
  ...
#end
  
#else
  No users found :()
#end

This gives me horrible performance and an OOME when the list gets too
long, because the check for #if($users) truthiness converts the whole
list collection into a String (which takes forever) which can be huge
(which can cause OOME).

I have now set the "directive.if.tostring.nullcheck=false" configuration
property (and written a set of wrapper classes around Collection classes
that throws an exception when toString is called, so things fail in
development) to avoid this, but also taken to using this check instead:

#if($users.size() > 0)

But this gets me a warning about the "size" method not existing on a
null object when the list is null. So I get junk in my logs when I do
things the hacky-way and I get performance problems and OOMEs when I do
things the "correct" way (at least, it looks totally correct).

> Regarding this spec:
>  - I'm not sure about getAsString() ; toString() is usually the standard
> way of getting the String representation and should be enough.
>  - I'm not convinced by the fact that zero should be true. I hear
> Nathan's point that for a display language, zero is as legitimate as any
> other number to be displayed. But it breaks the principle of least
> surprise, since each and every other language around, when not
> forbidding number towards boolean implicit conversion, consider zero as
> false.
> 
> So I'd rather go with:
> 
> $obj is null
> $obj is Boolean false
> $obj is Number zero (whatever Number variant)

For floating point values, does this have to be *zero*, or just close
enough to zero?

> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
> 
> Also, I noticed that Velocity weren't very consistent with literals. The
> only literal returning true is the 'true' literal. "foo" is false,
> whereas it should be consistent with $foo containing "foo".

Can we maybe make an exception for Collections? Maybe for a Collection
(or array), we never call toString() on it? [].toString will always give
you garbage (which will be truthy) and Collection.toString() will also
likely give you garbage and it will also always be truthy unless it's
(a) null or (b) the Collection implements toString in a surprising way
relative to java.util Collections.

-chris



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Michael Osipov as committer

[Christopher Schultz]

Nathan,

Hey! I didn't know I was on the PMC. :)

Vote below.

On 1/27/17 1:05 PM, Nathan Bubna wrote:
> Hey folks,
> 
> Michael Osipov has been rigorously and vigorously reviewing the progress of
> Engine 2.0, with commits specific and knowledgeable to be nigh
> indistinguishable from code itself. He's already an ASF committer (with
> Maven at least, maybe Jersey too?). In any case, he knows our ways and is
> actively contributing to Velocity. When a contributor starts keeping a
> committer busy (hang in there, Claude), we reward them with commit access
> so they can do it themselves. :)
> 
> What say ye?
> 
> 
> [X] +1 Sounds good.
> [ ] +/- 0 Not sure, because...
> [ ] -1 No. Because...

+1

-chris



signature.asc
Description: OpenPGP digital signature

Re: Reloading resources adding new macros

[Christopher Schultz]

Greg,

On 1/4/17 11:40 AM, Greg Huber wrote:
>> Velocity version?
> 
> The latest version ie 2.0.
> 
>> When you say you "shut down the container (tomcat)", >can you be more
> specific? Do you bounce the >application, or do you >terminate Tomcat and
> the JVM, >etc.?
> 
> Terminate tomcat shutdown.sh and then restart it.

If you terminate the JVM and the new instance doesn't pick up your
changes, then something is terribly wrong. You must be loading files
from a place you didn't expect, or something similar.

>> Did you write your own WebappResourceLoader (and if >so, why)?
> 
> Its a bit application so I do have my own version.
> 
> I did read on a list that it was an issue.  Think Nathan
> answered the post???
> 
> Maybe I have missed something in the code?
> 
> 
> public class WebappResourceLoader extends ResourceLoader {

Why not use the WebappResourceLoader provided by Velocity Tools?

-chris



signature.asc
Description: OpenPGP digital signature

Re: Reloading resources adding new macros

[Christopher Schultz]

Greg,

On 1/4/17 8:43 AM, Greg Huber wrote:
> The was one issue that has been around for ages, and I am not sure if it is
> possible to fix it.
> 
> If I have added a new macro into a velocity template file loaded via a
> resource loader, I have to shut down the container (tomcat) and restart for
> it to be picked up.  I will allow the contents of the macro to be changed
> but not a new macro.  I did try to see if I could fix it but without much
> success.
> 
> my velocity.properties :
> ..
> webapp.resource.loader.description=Webapp Resource Loader
> webapp.resource.loader.class=rendering.velocity.WebappResourceLoader
> webapp.resource.loader.cache=true
> webapp.resource.loader.path=/WEB-INF/velocity,/WEB-INF/velocity/templates,/WEB-INF/velocity/templates/feeds,/WEB-INF/velocity/templates/emails
> ...
> 
> If you are now familiar with the code you might be in a better position to
> see why I have to shut down for it to be picked up.

Velocity version?

When you say you "shut down the container (tomcat)", can you be more
specific? Do you bounce the application, or do you terminate Tomcat and
the JVM, etc.?

Did you write your own WebappResourceLoader (and if so, why)?

-chris



signature.asc
Description: OpenPGP digital signature

ApacheCon NA 2017

[Christopher Schultz]

All,

I'm going to be in Miami for this year's ApacheCon. In all the years
I've been going to ApacheCons, I've never seen a single presentation on
Velocity. That probably has something to do with the following:

1. Until recent work, it's been a "mature" project (no excitement)
2. It's not particularly sexy; it gets the job done

Are there any topics anyone has been considering presenting anytime
recently? Even something like "what's new in Velocity 2"? I'd certainly
like to (a) breathe new life into the community and (b) meet some
members of said community. A talk at ApacheCon can help out a lot with that.

I'll already be presenting at least one talk on Tomcat. I'd be happy to
work with someone to develop a presentation that promotes the Velocity
community in some way.

I've been a committer in name only for quite a few years, mostly because
of the maturity of this project (my work wasn't really required), so
perhaps I'm not the best choice for a subject-matter expert. But I'm
perfectly happy to stand up in front of people and talk about technology.

Is anyone else planning to attend? Would anyone be willing to present?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: [tools] Tools reeng

[Christopher Schultz]

Claude,

On 11/17/16 12:58 PM, Claude Brisson wrote:
> There are several things I'd like to do for the tools before releasing
> them:
> 
> 1) deprecate the ConversionTool:
> - date formatting and parsing methods are redundant with (and less
> complete than) DateTool ones.
> - number formatting and parsing methods are redundant with the
> NumberTool and MathTool ones, and also far less necessary now that a lot
> of automatic conversions are taken care of.
> - the only remaining feature is a toStrings() method (which does
> splitting and optional trimming). A single method does not legitimate
> the need for a tool, and in a web context, the ParameterTool already
> does it for GET/POST parameters. Still, we can have the method move
> elsewhere (but where? Maybe deprecate SortTool and have a CollectionTool
> do splitting and sorting?).
> 
> 2) deprecate MathTool number parsing and formatting methods, which are
> redundant with the NumberTool ones.

Okay to all of the above.

> 3) use explicit format names: numberFormat, timeFormat, dateFormat and
> timestampFormat, instead of a generic 'format' parameter defaulting to
> an ubiquitous 'default' value. I'd also like to have the default formats
> be the international formats used by HTML5 (RFC 3339).

+1000

> 4) On the same subject of formats, I'd also would like to introduce
> date/time format sniffing (as there are some good algorithms out there
> that we can borrow). We could maybe do the sniffing once and cache the
> detected format in the AST (but it should be configurable, and probably
> default to false).

What is the use-case here? Velocity should primarily be used for
output-generation, so the tools we provide should be for e.g.
java.util.Date -> java.lang.String, not the other way around.

I must admit, I've found myself using some Velocity-Tools classes as
hacks (e.g. re-formatting a date that is in a dumb format for some
reason), but it would be better not to encourage that kind of foolishness.

> 5) I'm pretty inclined to deprecate AlternatorTool, since all designers
> now use CSS for this purpose. Plus, we now have #if($foreach.index % 2)
> for this purpose.

Deprecating but not removing AlternatorTool is okay for the time being.
Some of us have to support ancient browsers like MSIE8 which don't
support CSS nth-child.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Commented] (VELOCITY-798) Velocity wraps java.lang.Error in org.apache.velocity.exception.MethodInvocationException

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15416412#comment-15416412
 ] 

Christopher Schultz commented on VELOCITY-798:
--

I would argue that java.lang.Error should not be caught and re-thrown as 
another exception. If you want to use a catch block for something, the original 
Error should be re-thrown at the end of it.

> Velocity wraps java.lang.Error in 
> org.apache.velocity.exception.MethodInvocationException
> -
>
> Key: VELOCITY-798
> URL: https://issues.apache.org/jira/browse/VELOCITY-798
> Project: Velocity
>  Issue Type: Bug
>  Components: Engine
>Affects Versions: 1.7
> Environment: n.a.
>Reporter: Alexander Veit
>
> If a method call throws a java.lang.Error, Velocity wraps it in a 
> MethodInvocationException, which itself is not a java.lang.Error.
> The spec says: "An Error is a subclass of Throwable that indicates serious 
> problems that a reasonable application should not try to catch."
> Wrapping the error hides it from applications and makes it difficult to 
> handle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: svn commit: r1696822 - in /velocity/tools/trunk: src/site/xdoc/ velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/ velocity-tools-view/src/main/java/org/apache/velocity/tools/vi

[Christopher Schultz]

Claude,

On 8/20/15 3:12 PM, Claude Brisson wrote:
> Yes, we should be using Velocity logging facade, but I just don't see
> for now how we should do this while preserving tools serialization.

A little late to the (logging) party, and this may be a bit off-topic,
but why bother using a Velocity-specific Logging facade when
commons-logging was built for that purpose and it is already pluggable?

Frederic Brier posted earlier in the summer about /removing/
commons-logging, so there's obviously some contention on how this all
ought to be done.

-chris



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1696822 - in /velocity/tools/trunk: src/site/xdoc/ velocity-tools-struts/src/main/java/org/apache/velocity/tools/struts/ velocity-tools-view/src/main/java/org/apache/velocity/tools/vi

[Christopher Schultz]

Mike,

On 8/31/15 1:48 PM, Mike Kienenberger wrote:
> Read the whole thread.

Yeah, I'm catching-up now.

> My understanding is that serialization of static commons-logging was
> the original problem needing fixed. slf4j doesn't have that issue.

I didn't think that static members were serialized. I suppose it depends
upon how the logging framework is being used. I rarely if ever use
non-static logging references, but of course I can't control everyone
else's coding styles :)

-chris



signature.asc
Description: OpenPGP digital signature

Re: Upgraded Commons and Velocity 2.0

[Christopher Schultz]

Mike,

On 5/28/15 3:41 PM, Mike Kienenberger wrote:
 No, maven isn't mandated.  I'd be happy if we reverted back to ant as
 Eclipse and ant is also what I use, and the only thing maven ever did
 for me to was to make everything more complicated and slow.
 
 For better or worse, it appears most of us old-time velocity users who
 would be motivated to contribute appear to prefer ant.
 
 I will add investigating what would be required to reinstate the old
 ant build for the 1.x branch to my list.  I suspect it's mostly
 adapting to the new new project layout, but my maven skills are
 minimal.

Let me see how painful building 1.7 is right now. Are you saying that
the grammar does not work for you?

When running mvn from a fresh checkout of Velocity 1.7
(svn:https://svn.apache.org/repos/asf/velocity/engine/tags/1.7,
last-changed r1040245), I get this:

Downloading:
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-junit/2.4.3/surefire-junit-2.4.3.jar
14K downloaded  (surefire-junit-2.4.3.jar)
[INFO] Surefire report directory:
/Users/chris/Documents/Eclipse/velocity-1.7/target/surefire-reports
org.apache.maven.surefire.booter.SurefireExecutionException: Unable to
instantiate POJO 'class org.apache.velocity.test.TestClassloader';
nested exception is java.lang.IllegalAccessException: Class
org.apache.maven.surefire.testset.PojoTestSet can not access a member of
class org.apache.velocity.test.TestClassloader with modifiers public;
nested exception is
org.apache.maven.surefire.testset.TestSetFailedException: Unable to
instantiate POJO 'class org.apache.velocity.test.TestClassloader';
nested exception is java.lang.IllegalAccessException: Class
org.apache.maven.surefire.testset.PojoTestSet can not access a member of
class org.apache.velocity.test.TestClassloader with modifiers public
org.apache.maven.surefire.testset.TestSetFailedException: Unable to
instantiate POJO 'class org.apache.velocity.test.TestClassloader';
nested exception is java.lang.IllegalAccessException: Class
org.apache.maven.surefire.testset.PojoTestSet can not access a member of
class org.apache.velocity.test.TestClassloader with modifiers public
java.lang.IllegalAccessException: Class
org.apache.maven.surefire.testset.PojoTestSet can not access a member of
class org.apache.velocity.test.TestClassloader with modifiers public
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:102)
at java.lang.Class.newInstance(Class.java:436)
at
org.apache.maven.surefire.testset.PojoTestSet.init(PojoTestSet.java:55)
at
org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(JUnitDirectoryTestSuite.java:64)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96)
at
org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209)
at org.apache.maven.surefire.Surefire.run(Surefire.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

I have absolutely no idea how to turn off things like unit tests in
Maven to see if I can even get an artifact.

If I run mvn compile it tells me there's nothing do to, but my working
copy of svn has no changes. Nothing to do, but nothing done, seems like.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Upgraded Commons and Velocity 2.0

[Christopher Schultz]

Jacob,

On 5/28/15 9:13 AM, Jacob Champlin wrote:
 So building 2.0 has not gone well.  There are no valid instructions
 online, eventually I figured out:
 
 $ svn checkout http://svn.apache.org/repos/asf/velocity/engine/trunk
 velocity-master
 $ cd velocity-master
 $ mvn
 
 However, almost all the velocity-core test cases fail, which does not
 inspire confidence.

I must admit that I stopped doing anything on Velocity/Tools after trunk
went to using Maven. I can't figure out how to build it in Eclipse, so
it's currently dead to me :(

Granted, that's my own failure, but given that Velocity 2.0 developed
seemed to have stalled long ago, it seemed like sticking with Velocity
1.7 wasn't a big problem.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Upgraded Commons and Velocity 2.0

[Christopher Schultz]

Jacob,

On 5/28/15 11:21 AM, Jacob Champlin wrote:
 
 
 On 05/28/2015 10:48 AM, Mike Kienenberger wrote:
 On Thu, May 28, 2015 at 10:42 AM, Antonio Petrelli
 But when repository branches do not build from source, releases do not
 build from source, and no one seems to be around to suggest how it's
 supposed to work, the Velocity development team destroys the ability
 to attract and maintain new community members, which can only lead to
 the project's slow death and migration to the Attic.


 And probably it is the best, but saddest, thing to do.

 If I agreed with that, I wouldn't be part of this conversation.
 People are still willing to contribute.

 I have enough of a vested interest in Velocity that I will eventually
 make progress on this issue.  :)

 But now is the time to start enabling contributors to eventually
 become committers and then PMC members while there are still
 interested and willing contributors in the community.

 
 I would like to point out that we are very happy running Velocity 1.7,
 in fact there is not a single new feature we want.

+1

 So we agree
 its a stable mature product that doesn't need a lot of changes.  Our
 problem is the world around it has been changing, and Velocity isn't
 keeping up.  Apache Commons in particular.  Looks like its easy to go to
 latest lang, and digester, but collections is a different beast.  So
 velocity
 isn't even keeping up with its dependencies from the same organization. 
 Not to mention I am sure the code could benefit from newer java features.

-0

Only if it actually improves the ability to maintain the code. Jumping
to new language features is a bit of a risk, and should only be done if
there's a compelling reason.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Spent time working on Velocity

[Christopher Schultz]

Nathan,

On 11/26/14 4:55 PM, Nathan Bubna wrote:
 On Wed, Nov 26, 2014 at 1:41 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 ...
 
 If all logging could be replaced by using commons-logging, then all will
 be well. commons-logging is just a pass-through for whatever logger is
 really being used... log4j, slf4j, java.util.logging, etc. Most ASF
 projects use it already as the logging framework just to make things
 easier for everyone. It's super lightweight and nobody has to fight over
 which logging framework is best since it plugs into all of them.

 
 I'm ok with either. Whoever wants to do the work can pick, AFAIC.

Agreed. I'm certainly not motivated to rip-out any logging in 1.x, but
2.x seems ripe for such things if they haven't already happened. I think
1.x still uses Avalon, which has been abandoned (right?).

 I seem to recall having a bear of a time building the 2.x branch, but my
 Maven-fu is not strong. I admit having a fear of Maven because I don't
 understand how it works and prefer Ant's ability to do exactly what I
 tell it to do, instead of what it thinks is best for me ;)
 
 The only thing you have to fear is fear itself. And dependency hell, of
 course.

Yes. And builds that take way longer than necessary. One of our projects
at $work uses Maven to build and that part of the build (which
represents maybe 5% of the total Java code to compile) takes roughly 90%
of the build time of the rest of the code, not including actually
fetching those dependencies. :(

 I'm interested to hear about the fixes to the core library, though, and
 the unit tests that weren't being invoked and that were failing. Perhaps
 there is a reason they had been avoided. If there are legitimate fixes
 available from Frederick, we should be looking at those primarily,
 especially from a potential back-porting perspective. That is, if 1.7 is
 in fact broken, let's fix it.

 
 As long as 1.x stays relatively stable, fixes for it are a great thing.

+1

My feeling is that 1.x is totally in maintenance mode: we should only be
fixing things that are actually broken. New features, etc. should all go
into 2.x.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Spent time working on Velocity

[Christopher Schultz]

All,

On 9/26/14 12:22 PM, Sergiu Dumitriu wrote:
 On 09/25/2014 11:27 PM, Nathan Bubna wrote:
 https://github.com/apache/velocity-engine

 https://github.com/apache/velocity-engine/tree/2.0_Exp

 Now, that said, i've not used the git mirror. The Subversion repository may
 still be considered the primary one by the infrastructure guys, but i
 assume they work together well enough.
 
 AFAIK, subversion is the only place where commits happen, the GitHub
 repos are read-only mirrors, but they're good for getting contributions
 in. Committers have to get the GitHub patches and push them to the
 Apache SVN repo.
 
 As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother
 with them, for now.

 If slf4j works better for Android, that seems like a fine log adaptor to me.
 
 +1 for slf4j, it's a generic enough abstraction of logging frameworks,
 so LogChute is really not needed.

Very late to the party...

If all logging could be replaced by using commons-logging, then all will
be well. commons-logging is just a pass-through for whatever logger is
really being used... log4j, slf4j, java.util.logging, etc. Most ASF
projects use it already as the logging framework just to make things
easier for everyone. It's super lightweight and nobody has to fight over
which logging framework is best since it plugs into all of them.

I seem to recall having a bear of a time building the 2.x branch, but my
Maven-fu is not strong. I admit having a fear of Maven because I don't
understand how it works and prefer Ant's ability to do exactly what I
tell it to do, instead of what it thinks is best for me ;)

I'm interested to hear about the fixes to the core library, though, and
the unit tests that weren't being invoked and that were failing. Perhaps
there is a reason they had been avoided. If there are legitimate fixes
available from Frederick, we should be looking at those primarily,
especially from a potential back-porting perspective. That is, if 1.7 is
in fact broken, let's fix it.

-chris

 Here's the CLA: http://www.apache.org/licenses/icla.txt

 On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com
 wrote:

 Hi Nathan,

 I looked for the Velocity Git repo and could not find it on the Apache Git
 page.  I just started with the 1.7 source code and initialized my own git
 repo and was making changes there.  If you can post the git URL, I could
 clone it and try and meld my changes on to a branch and push the repo to
 Github so everyone could see it and evaluate it.

 While I am not familiar with Anakia/Texen, my thought was that if others
 were interested, the single module Maven project would become a
 multi-module project with at least 3 child modules: velocity-core,
 velocity-anakia, and velocity-texen.
 
 I would recommend working on top of the 2.0 branch, it already has a
 good starting point for a module-based Maven build. Anakia and Texen
 have already been moved out of the engine (their repos are not mirrored
 on GitHub).
 
 I didn't start my current project using Velocity.  My background is more
 enterprise systems and not Android.  So I started writing an XML schema to
 represent my domain objects and started bumping my head on a number of
 Android limitations, specific to XML.  BTW, Android development tools rock,
 but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans 
 https://code.google.com/p/android/issues/detail?id=76265.  There are
 several options out there for template engines, but all the ones that would
 work on Android seemed very limited.  As mentioned, I'd used Velocity
 several times, years ago.  So I figured I'd give it a whirl.

 Log4j can apparently work on Android, but enough posts were out there that
 made me nervous.  Having already experienced problems with libraries, I
 decided to pare down Velocity to its minimum. That is the reason for
 trimming out the LogChute, Commons-Logging, Log4J, etc.  It's amazing how
 much code could be eliminated.  With IoC, the tests might even get leaner.
 SLF4J http://www.slf4j.org/ is a real thin facade for logging and there
 are adapters to all the other logging frameworks.  It is lightweight and
 there is an slf4j-android http://www.slf4j.org/android/ project.
 
 What are your plans for IoC? Will you be using JSR-299? Any framework in
 mind?
 
 I was not even aware of a 2.x branch, what its goals are, or what has been
 done.  I can sign a CLA.  Could you please post me the git repo that has
 the 2.x code?  BTW, my middle name is Nathan :).

 Fred


 On 09/25/2014 05:49 PM, Nathan Bubna wrote:

 Hi Frederick!

 Thanks for posting this here. Currently, we have a 1.x branch that is
 stable and in a long-term maintenance mode and a 2.x branch that is not
 really ready for consumption yet. To be honest, it's been so long since i
 worked on 2.x that i can't remember what changes we did get done (i could
 go look).  Most of the core committers are, for one reason or another,
 focusing their development energies 

Re: Velcity and Texen DOAPs - trivial fixes, needs Velocity committer assistance please

[Christopher Schultz]

Sebb,

On 4/16/14, 10:58 AM, sebb wrote:
 The Velocity and Texen DOAPs are the only ones that don't use the Apache 
 prefix
 
 See TEXEN-18 and VELOCITY-848
 
 Please could one of the Velocity committers fix the DOAPS?

What exactly needs to be fixed? I can fix in svn... not sure how the
site gets built.

-chris



signature.asc
Description: OpenPGP digital signature

Re: [PROPOSAL][REPORT] Apache Velocity - May 2013

[Christopher Schultz]

Nathan,

On 5/6/13 12:17 PM, Nathan Bubna wrote:
 Well, even though you're not technically on the PMC, we don't keep a
 division between committers and PMC in practice.  Your votes count
 now, as far as anything practical.  And we'll put you on the PMC
 formally in just a few months, per typical practice. :)

... at least with some committers ;)

-chris



signature.asc
Description: OpenPGP digital signature

[tools] Interest in (or aversion to) adding CSV escaping to EscapeTool

[Christopher Schultz]

All,

I'd like to use Velocity to produce CSV files and I have a routine I've
been using for years in automated reports to escape field values for
CSV. Any objections to adding it to EscapeTool?

Actually... StringEscapeUtils (from commons-lang, which does most of
EscapeTool's actual work) has an escapeCsv method already, though it
does scan every String twice for  and , characters, and it does not
handle leading and trailing whitespace (my code wraps such data in s).

Any comments?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: Velocity Macro Stack Traces Patch

[Christopher Schultz]

Sergiu and Benson,

On 10/2/12 4:40 PM, Sergiu Dumitriu wrote:
 On 10/02/2012 02:25 PM, Benson Margulies wrote:
 Sergey,

 As I understand it, since the birth of Httpd and the license, patches
 sent to the mailing list (a) don't require a CLA and (b) are
 acceptable contributions.

 The idea is this: users get the source of Apache stuff under the terms
 of the license, and that license specifies that, if they send in a
 patch, it's a contribution.

 CLAs are only required for significant new work that is not a derived
 work of the existing code.
 
 I see, thanks for the clarification.

Meanwhile, neither of you have made a contribution through this
discussion :(

-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Reopened] (VELTOOLS-152) ValidatorTool generates invalid XHTML even when in XHTML mode

[Christopher Schultz (Reopened) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz reopened VELTOOLS-152:
--


So, this doesn't fix the issue properly.

What I did was essentially change '' to 'amp', but that's not appropriate 
unless the page is actually in XML rendering mode, not just XHTML.

This needs a more nuanced fix.


 ValidatorTool generates invalid XHTML even when in XHTML mode
 -

 Key: VELTOOLS-152
 URL: https://issues.apache.org/jira/browse/VELTOOLS-152
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
Reporter: Christopher Schultz
Assignee: Christopher Schultz
 Fix For: 2.0.x, 2.1


 When using the validator tool in XHTML mode, the main validate method emits 
 code like this:
 function validateMyForm(form) {
   if (bCancel)
 return true;
   else
   {
 var formValidationResult; formValidationResult = validateInteger(form)  
 validateRequired(form)  validateMaxLength(form)  validateMask(form)  
 validateIntRange(form);
 return (formValidationResult == 1);
   }
 Note the use of bare  characters, which is not valid XHTML.
 Most web browsers will ignore this little quirk unless they are in XML 
 parsing mode (usually enabled by setting the content-type to 
 application/xhtml+xml).
 Here is a reference to the discussion on the user list:
 http://markmail.org/thread/jtuqduopuikwtvqm

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-152) ValidatorTool generates invalid XHTML even when in XHTML mode

[Christopher Schultz (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-152.
--

   Resolution: Fixed
Fix Version/s: 2.1
   2.0.x

 ValidatorTool generates invalid XHTML even when in XHTML mode
 -

 Key: VELTOOLS-152
 URL: https://issues.apache.org/jira/browse/VELTOOLS-152
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
Reporter: Christopher Schultz
Assignee: Christopher Schultz
 Fix For: 2.0.x, 2.1


 When using the validator tool in XHTML mode, the main validate method emits 
 code like this:
 function validateMyForm(form) {
   if (bCancel)
 return true;
   else
   {
 var formValidationResult; formValidationResult = validateInteger(form)  
 validateRequired(form)  validateMaxLength(form)  validateMask(form)  
 validateIntRange(form);
 return (formValidationResult == 1);
   }
 Note the use of bare  characters, which is not valid XHTML.
 Most web browsers will ignore this little quirk unless they are in XML 
 parsing mode (usually enabled by setting the content-type to 
 application/xhtml+xml).
 Here is a reference to the discussion on the user list:
 http://markmail.org/thread/jtuqduopuikwtvqm

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-126) XSS Vulnerability when using struts/ErrorsTool.getMsgs

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224501#comment-13224501
 ] 

Christopher Schultz commented on VELTOOLS-126:
--

ErrorsTool now uses StrutsUtils.errorMarkup whose code looks a little different:

String message;
while (reports.hasNext())
{
message = null;
ActionMessage report = (ActionMessage)reports.next();
if (resources != null  report.isResource())
{
// TODO: VELTOOLS-126 - XSS vulnerability here
// TODO: unless we HTML-escape some stuff
message = resources.getMessage(locale,
   report.getKey(),
   report.getValues());
}

results.append(prefix);

if (message != null)
{
results.append(message);
}
else
{
// TODO: VELTOOLS-126: HTML-escape the key
results.append(report.getKey());
}

results.append(suffix);
results.append(\r\n);
}

I think if you look at the TODO comments I've added, it makes sense to 
HTML-escape the values passed to resources.getMessage() and the key if there is 
no message. Of course, ErrorsTool can be used in non-HTML contexts, so the 
whole thing must be configurable. I'll take Nathan's suggestion of making it a 
tool-parameter, but I think it makes sense to make the default configuration to 
escape HTML since this is a security (XSS) issue.

 XSS Vulnerability when using struts/ErrorsTool.getMsgs
 --

 Key: VELTOOLS-126
 URL: https://issues.apache.org/jira/browse/VELTOOLS-126
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 1.4, 2.x
 Environment: Identified in velocity-tools 1.4, verified by reading 
 code in trunk.
Reporter: Christopher Schultz

 The code for ErrorsTool.getMsgs goes roughly like this:
 String message = message(errors.header);
 foreach(error) {
   message += message(errors.prefix) + error + message(errors.suffix)
 message += message(errors.footer)
 return message;
 This is easily open to an XSS attack when an error message contains user 
 input.
 Honestly, I'm not entirely sure if we should even do anything about this, 
 because the ErrorsTool is not strictly for use in an HTML context, so 
 escaping the error message itself may not be appropriate. Also, the message 
 itself may contain markup which the developer wants to remain, while the user 
 input should be escaped.
 It's possible that the solution to this problem is to put a big warning on 
 the tool that XSS attacks are very easy using this tool.
 I've been running with it for years, and didn't notice until today. I 
 replaced my use of errors.getMsgs with this:
 $!msg.errors.header
 #foreach($error in $errors.get($fieldName))
 $!msg.errors.prefix#htmlEscape($error)$!msg.errors.suffix
 #end
 $!msg.errors.header
 ...which is appropriate for my uses, but might not work for everyone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-152) ValidatorTool generates invalid XHTML even when in XHTML mode

[Christopher Schultz (Created) (JIRA)]

ValidatorTool generates invalid XHTML even when in XHTML mode
-

 Key: VELTOOLS-152
 URL: https://issues.apache.org/jira/browse/VELTOOLS-152
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
Reporter: Christopher Schultz
Assignee: Christopher Schultz


When using the validator tool in XHTML mode, the main validate method emits 
code like this:

function validateMyForm(form) {
  if (bCancel)
return true;
  else
  {
var formValidationResult; formValidationResult = validateInteger(form)  
validateRequired(form)  validateMaxLength(form)  validateMask(form)  
validateIntRange(form);

return (formValidationResult == 1);
  }

Note the use of bare  characters, which is not valid XHTML.

Most web browsers will ignore this little quirk unless they are in XML parsing 
mode (usually enabled by setting the content-type to application/xhtml+xml).

Here is a reference to the discussion on the user list:
http://markmail.org/thread/jtuqduopuikwtvqm


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-152) ValidatorTool generates invalid XHTML even when in XHTML mode

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13223732#comment-13223732
 ] 

Christopher Schultz commented on VELTOOLS-152:
--

Fixed in trunk: r1297753
Fixed in 2.0.x branch: r1297754

 ValidatorTool generates invalid XHTML even when in XHTML mode
 -

 Key: VELTOOLS-152
 URL: https://issues.apache.org/jira/browse/VELTOOLS-152
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
Reporter: Christopher Schultz
Assignee: Christopher Schultz

 When using the validator tool in XHTML mode, the main validate method emits 
 code like this:
 function validateMyForm(form) {
   if (bCancel)
 return true;
   else
   {
 var formValidationResult; formValidationResult = validateInteger(form)  
 validateRequired(form)  validateMaxLength(form)  validateMask(form)  
 validateIntRange(form);
 return (formValidationResult == 1);
   }
 Note the use of bare  characters, which is not valid XHTML.
 Most web browsers will ignore this little quirk unless they are in XML 
 parsing mode (usually enabled by setting the content-type to 
 application/xhtml+xml).
 Here is a reference to the discussion on the user list:
 http://markmail.org/thread/jtuqduopuikwtvqm

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [OT] tools-2.1-dev and engine-2.x

[Christopher Schultz]

Nathan,

On 4/13/11 12:03 PM, Nathan Bubna wrote:
 On Wed, Apr 13, 2011 at 4:19 AM, Claude Brisson cla...@renegat.net wrote:
 On 2011-04-13 11:57, Antonio Petrelli wrote:

 Hi Claude

 2011/4/13 Claude Brissoncla...@renegat.net
 ...

 Then I'd vote for the first solution: have tools-2.1 require engine-2.x once
 it's released. After all, we can backport important changes to tools-2.0.x.
 ...
 
 I agree.  At this point, tools is evolving slowly, and what time i do
 have to develop velocity will be largely spent on engine 2.  I think
 it is fine to release fixes to Tools in the 2.0.x branch and have 2.1
 be where we drop support for both Tools 1 config and Engine 1.

Can you confirm that your expectation is that Tools 2.0.x will have at
least one more release? I was getting ready to make a few changes and I
want to make sure that I commit to the right place. If 2.0.x is
essentially dead, then I'll only commit to trunk and leave 2.0.x alone.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Commented] (VELTOOLS-136) SortTool fails on null values

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197024#comment-13197024
 ] 

Christopher Schultz commented on VELTOOLS-136:
--

Did you mean that SortTool doesn't accept null collections, or does not accept 
collections which contain null elements?

If the latter, where do you expect null elements to go? The end of the list? 
The beginning?

 SortTool fails on null values
 -

 Key: VELTOOLS-136
 URL: https://issues.apache.org/jira/browse/VELTOOLS-136
 Project: Velocity Tools
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Canny
 Fix For: 2.0.x


 The sort tool uses comparison = right.compareTo(null); on line 276. That 
 can fail in the case the right object compareTo() method can
 not handle null params. I.e. java.util.Date can not handle that, so the sort 
 result is empty. The sort tool should support sorting of collections with
 null values.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [OT] tools-2.1-dev and engine-2.x

[Christopher Schultz]

Nathan,

On 1/31/12 12:39 PM, Nathan Bubna wrote:
 Do you want a new 2.0 release?  I can't recall offhand if there is/was
 a particular need or demand for one.

No, but I was going to make some changes that I need fixing :)

So, the question is whether to commit to trunk and back-port to 2.0.x,
or not bother back-porting because 2.0.x is essentially done.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: Update on VELTOOLS-143

[Christopher Schultz]

Nathan,

On 1/19/12 12:45 PM, Nathan Bubna wrote:
 https://issues.apache.org/jira/browse/VELOCITY-143  ??

No, VELTOOLS-143:

https://issues.apache.org/jira/browse/VELTOOLS-143

-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Commented] (VELTOOLS-150) VelocityLayoutServlet allows clients to specify layout without performing any security checks.

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13189838#comment-13189838
 ] 

Christopher Schultz commented on VELTOOLS-150:
--

Sure, I can do a simple fix like that.

I think I'd also like to introduce a configuration setting that allows this 
feature to be disabled entirely. While I'd prefer to leave it disabled by 
default, it might actually break someone's webapp so we should probably wait 
for another major release before making that kind of change.


 VelocityLayoutServlet allows clients to specify layout without performing 
 any security checks.
 

 Key: VELTOOLS-150
 URL: https://issues.apache.org/jira/browse/VELTOOLS-150
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 1.4, 2.0
 Environment: Velocity 1.7, Velocity Tools 2.0.
 Confirmed also affects Velocity 1.4, Velocity Tools 1.4.
Reporter: Christopher Schultz
Priority: Critical
  Labels: security

 For reference:
 http://markmail.org/thread/43cz2dymzmxjjrq5

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Update on VELTOOLS-143

[Christopher Schultz]

All,

I logged VELTOOLS-143 a while ago and I'd like to get it fixed for an
upcoming release of my own software.

Can someone help me understand why mailto: links don't accept params?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Commented] (VELOCITY-731) Velocity 1.6 performance is degraded by introduced toString() calls

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187966#comment-13187966
 ] 

Christopher Schultz commented on VELOCITY-731:
--

Colin,

So your bean has a toString method that issues a JDBC call? That just seems 
like a bad idea in the first place.

There are other ways to check for the existence of a variable. For instance, 
instead of:

#if($objectWithExpensiveToStringMethod)

You can do this:

#if($objectWithExpensiveToStringMethod.class)

Every class has a getClass method (inherited from java.lang.Object) which will 
return null/false only if the object reference itself is null, so although it's 
less obvious what's going on (the .class on the end might raise some eyebrows), 
it gets the job done and doesn't hit your database.

 Velocity 1.6 performance is degraded by introduced toString() calls
 ---

 Key: VELOCITY-731
 URL: https://issues.apache.org/jira/browse/VELOCITY-731
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6, 1.6.1, 1.6.2
 Environment: Apache Velocity 1.6.2
Reporter: Jörgen Rydenius
 Fix For: 1.6.x, 1.7

 Attachments: configurable_tostring_nullcheck_patch.txt


 As part of VELOCITY-531, r686428 introduced frequent calls to toString() just 
 to check if toString() != null. If toString() implementations are slightly 
 complex, and very frequently executed, these calls will degrade the site 
 performance. Are they at all necessary? What kind of object would use null as 
 a return value for toString()? Is it possible to remove these toString() 
 calls from the velocity code again?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELTOOLS-150) VelocityLayoutServlet allows clients to specify layout without performing any security checks.

[Christopher Schultz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13182702#comment-13182702
 ] 

Christopher Schultz commented on VELTOOLS-150:
--

I see us having several options, here:

1. Disable this feature
2. Make this feature optional and configurable, with the default being 
/disabled/
3. Lock-down the process that allows certain paths to protect the webapp when 
this feature /is/ used

I think that #2 is a good idea in general: I suspect that most people don't 
actually use this feature, so disabling it will certainly eliminate this attack 
vector.

#3 might be touchy, since any file in a webapp - not just in WEB-INF or 
META-INF - could potentially be sensitive. It's a reasonable assumption that 
things in WEB-INF and META-INF should be protected by this particular feature, 
but it might not be straightforward since the layout directory is relative to 
the webapp, and then the layout selected by the request parameter will be 
relative to that. We may have to normalize the path and then compare it to 
known sensitive path prefixes. I'm not sure how to get the container to 
normalize a path for us, though. Maybe we just need to look for .. in the 
layout name and ignore anything that looks like that. Suggestions are certainly 
welcome.

Certainly, templates or servlets, etc. themselves need to be exempt from these 
measures in case programmers want to use templates that are outside the norm: 
these security rules should probably only be applied when the layout is being 
selected from the request parameters. Request attributes, for instance, should 
be considered trusted.

 VelocityLayoutServlet allows clients to specify layout without performing 
 any security checks.
 

 Key: VELTOOLS-150
 URL: https://issues.apache.org/jira/browse/VELTOOLS-150
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 1.4, 2.0
 Environment: Velocity 1.7, Velocity Tools 2.0.
 Confirmed also affects Velocity 1.4, Velocity Tools 1.4.
Reporter: Christopher Schultz
Priority: Critical
  Labels: security

 For reference:
 http://markmail.org/thread/43cz2dymzmxjjrq5

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-150) VelocityLayoutServlet allows clients to specify layout without performing any security checks.

[Christopher Schultz (Created) (JIRA)]

VelocityLayoutServlet allows clients to specify layout without performing any 
security checks.


 Key: VELTOOLS-150
 URL: https://issues.apache.org/jira/browse/VELTOOLS-150
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 2.0, 1.4
 Environment: Velocity 1.7, Velocity Tools 2.0.
Confirmed also affects Velocity 1.4, Velocity Tools 1.4.
Reporter: Christopher Schultz
Priority: Critical


For reference:
http://markmail.org/thread/43cz2dymzmxjjrq5


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-148) LinkTool.addAllParameters causes ignored parameters to pollute parent link objects

[Christopher Schultz (JIRA)]

LinkTool.addAllParameters causes ignored parameters to pollute parent link 
objects


 Key: VELTOOLS-148
 URL: https://issues.apache.org/jira/browse/VELTOOLS-148
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity-Tools 2.0
Reporter: Christopher Schultz


The following code will not perform as expected with $link represents an 
instance of view.tools.LinkTool:

#set($forward = $link.setRelative('/foo').addQueryData('bar', 'baz'))
one = $forward.addAllParameters()br /
two = $forward.addAllParameters()br /

The addQueryData appears to be required in order to make this fail.

The addAllParameters method calls view.LinkTool.addRequestParamsExcept which 
calls view.LinkTool.addRequestParams which calls generic.LinkTool.duplicate() 
in order to duplicate the LinkTool before calling view.tools.setParam 
repeatedly on it.

generic.LinkTool.duplicate clones the LinkTool object including the 
view.tools.LinkTool's reference to the parametersToIgnore field. The child 
instances of this LinkTool will then have their ignores list bleed-into the 
parent (and also other siblings) and the ultimate effect is that LinkTool 
objects derived from that common root will be unable to call addAllParameters() 
because all parameters will have been added to that ignores list after the 
first invocation.

The obvious solution seems to be that view.tools.LinkTool needs to override the 
duplicate(boolean) method in order to clone the ignores list.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-149) LinkTool.addRequestParams methods are difficult to use from VTL due to their String[] parameter type

[Christopher Schultz (JIRA)]

LinkTool.addRequestParams methods are difficult to use from VTL due to their 
String[] parameter type


 Key: VELTOOLS-149
 URL: https://issues.apache.org/jira/browse/VELTOOLS-149
 Project: Velocity Tools
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity-Tools 2.0
Reporter: Christopher Schultz
Priority: Minor


If I call addRequestParams() with no argument, things work as expect. On the 
other hand, this does not work:

#set($ignoreList = ['foo'])
$link.relative('/bar').addRequestParamsExcept($ignoreList)

I get an invalid reference log message and the above $link... text is 
rendered as written instead of evaluating successfully.

The problem is that the ignoreList is a List and it needs to be String[]. 
Velocity will auto-convert Lists into Object[] if appropriate, but the 
resulting object type is Object[] and not String[].

There does not appear to be a way to create a String[] from a Velocity 
template, so using addRequestParams and the other, similar methods will be very 
difficult to use with an argument.

LinkTool.addRequestParams and friends should be modified to accept Object[] 
arguments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-148) LinkTool.addAllParameters causes ignored parameters to pollute parent link objects

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-148.
--

   Resolution: Fixed
Fix Version/s: 2.0.x

Fixed in r1151642:

New view.tools.LinkTool.duplicate(boolean) method.
New unit test.


 LinkTool.addAllParameters causes ignored parameters to pollute parent link 
 objects
 

 Key: VELTOOLS-148
 URL: https://issues.apache.org/jira/browse/VELTOOLS-148
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityView
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity-Tools 2.0
Reporter: Christopher Schultz
 Fix For: 2.0.x


 The following code will not perform as expected with $link represents an 
 instance of view.tools.LinkTool:
 #set($forward = $link.setRelative('/foo').addQueryData('bar', 'baz'))
 one = $forward.addAllParameters()br /
 two = $forward.addAllParameters()br /
 The addQueryData appears to be required in order to make this fail.
 The addAllParameters method calls view.LinkTool.addRequestParamsExcept which 
 calls view.LinkTool.addRequestParams which calls generic.LinkTool.duplicate() 
 in order to duplicate the LinkTool before calling view.tools.setParam 
 repeatedly on it.
 generic.LinkTool.duplicate clones the LinkTool object including the 
 view.tools.LinkTool's reference to the parametersToIgnore field. The 
 child instances of this LinkTool will then have their ignores list 
 bleed-into the parent (and also other siblings) and the ultimate effect is 
 that LinkTool objects derived from that common root will be unable to call 
 addAllParameters() because all parameters will have been added to that 
 ignores list after the first invocation.
 The obvious solution seems to be that view.tools.LinkTool needs to override 
 the duplicate(boolean) method in order to clone the ignores list.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-149) LinkTool.addRequestParams methods are difficult to use from VTL due to their String[] parameter type

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-149.
--

   Resolution: Fixed
Fix Version/s: 2.0.x

Fixed in r1151648.

- Change methods to accept Object[] instead of String[].

 LinkTool.addRequestParams methods are difficult to use from VTL due to their 
 String[] parameter type
 

 Key: VELTOOLS-149
 URL: https://issues.apache.org/jira/browse/VELTOOLS-149
 Project: Velocity Tools
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity-Tools 2.0
Reporter: Christopher Schultz
Priority: Minor
 Fix For: 2.0.x


 If I call addRequestParams() with no argument, things work as expect. On the 
 other hand, this does not work:
 #set($ignoreList = ['foo'])
 $link.relative('/bar').addRequestParamsExcept($ignoreList)
 I get an invalid reference log message and the above $link... text is 
 rendered as written instead of evaluating successfully.
 The problem is that the ignoreList is a List and it needs to be String[]. 
 Velocity will auto-convert Lists into Object[] if appropriate, but the 
 resulting object type is Object[] and not String[].
 There does not appear to be a way to create a String[] from a Velocity 
 template, so using addRequestParams and the other, similar methods will be 
 very difficult to use with an argument.
 LinkTool.addRequestParams and friends should be modified to accept Object[] 
 arguments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Closed] (VELTOOLS-52) ValidatorTool javascript generator can generate invalid Javascript

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz closed VELTOOLS-52.
---


 ValidatorTool javascript generator can generate invalid Javascript
 --

 Key: VELTOOLS-52
 URL: https://issues.apache.org/jira/browse/VELTOOLS-52
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 1.2
 Environment: Using JDK1.4.2 / Linux 2.4 kernel / Tomcat 4.1
Reporter: Christopher Schultz
Assignee: Nathan Bubna
 Fix For: 1.2

 Attachments: ValidatorTool.diff


 ValidatorTool can create invalid javascript in a few situations.
 Here is an example of such a situation and also an example of the invalid 
 javascript it generates.
 Suppose you have the following dynamic action form validation rules defined 
 (this is actually text field which is intended to be used as an other input 
 when a drop-down has the value of Other).
 pre
   field property=selectOther
  depends=validwhen,maxlength
page=1
 arg0 key=prompt.selectOther/
   arg1 name=maxlength key=${var:maxlength} resource=false /
   varvar-namemaxlength/var-namevar-value255/var-value/var
 var
   var-nametest/var-name
   var-value
 (((select == Other) and (*this* != null)) or
   (select != Other))
   /var-value
   /var
   /field
 /pre
 When ValidatorTool generates Javascript for this, you get the following:
 pre
 .
 .
 .
 this.a3 = new Array(orgTypeOther, The field Organization Type cannot 
 be greater than 255 characters., new Function (varName, 
 this.maxlength='255'; this.test='(((orgType == Other) and (*this* != 
 null)) or
   (orgType != Other))';  return this[varName];));
 .
 .
 .
 /pre
 Note that there is a newline in the string literal (invalid) and that the 
 double-quotes used in my validwhen rule have not been escaped, which 
 prematurely ends the double-quoted string starting with 
 codethis.maxlength/code, which really confuses the Javascript 
 interpreter.
 It turns out that switching from double-quotes to single-quotes doesn't help, 
 since there are also single-quoted strings within that double-quoted string, 
 so basically it won't work no matter what you do (since backslash-escaping 
 the quotes will cause the validwhen test itself to become invalid.
 I see two solutions: properly escape the variable values being dumped into 
 Javascript, or avoid adding the test variable to the Javascript, since it 
 will be ignored, anyway.
 I propose fixing the escaping, since there may be other validator var 
 values with this same problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Closed] (VELTOOLS-58) ValidatorTool does not respect 'bundle' property for message elements when generating client-side validation code.

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz closed VELTOOLS-58.
---


 ValidatorTool does not respect 'bundle' property for message elements when 
 generating client-side validation code.
 --

 Key: VELTOOLS-58
 URL: https://issues.apache.org/jira/browse/VELTOOLS-58
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 1.2, 1.3
 Environment: JDK 1.4.2_09 / Tomcat 4.1.31 / Struts 1.2.7 / 
 Commons-Validator 1.1.4
Reporter: Christopher Schultz
 Fix For: 1.3

 Attachments: VELTOOLS-58.patch, ValidatorTool.java


 I recently decided to split my application properties files into multiple 
 bundles instead of one huge bundle in an effort to maintain some order. This 
 required me to change my validation configuration to include the bundle 
 property on my message elements:
   field property=questionTypeId
 depends=required,integer
 arg position=0 bundle=Clinician 
 key=prompt.responseOption.questionTypeId/
   /field
 The ValidatorTool.getDynamicJavascript does not respect this setting and so I 
 get messages like The field ???en_US.responseOption.questionTypeId??? is 
 required..
 ValidatorTool.getDynamicJavascript first gets the global message bundle and 
 re-uses it for all of the error messages emitted by the javascript generator:
   String message = Resources.getMessage(messages, locale, va, 
 field);
 In order to respect the msg's bundle, the code should instead be this:
   String message = Resources.getMessage(app,
 request,
 messages,
 locale,
 va,
 field);
 It turns out that this doesn't fix the problem, although I'm sure that this 
 change should be made. Perhaps someone with a better understanding of 
 Struts/Validator/VelocityTools could shed some light on this situation.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Closed] (VELTOOLS-89) LinkTool's addQueryData method should automatically add an 'ignore' so addAllParameters will ignore manually-added query data

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz closed VELTOOLS-89.
---


 LinkTool's addQueryData method should automatically add an 'ignore' so 
 addAllParameters will ignore manually-added query data
 -

 Key: VELTOOLS-89
 URL: https://issues.apache.org/jira/browse/VELTOOLS-89
 Project: Velocity Tools
  Issue Type: Improvement
  Components: VelocityView
Reporter: Christopher Schultz
Priority: Trivial
 Fix For: 1.x, 1.4, 2.x

 Attachments: VELTOOLS-89.diff


 Currently, the LinkTool requires that, for each parameter you intend to 
 override from the current request (when using addAllParameters), you do 
 something like this:
 $link.addIgnore(foo).addQueryData(foo, bar).addAllParameters()
 It is almost always the case that the foo parameter should be ignored from 
 the current request because it's value is being explicitly set by the 
 addQueryData call.
 This should be the default behavior, with the current behavior being 
 configurable via the toolbox setup.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-144) DateTool can be improved to allow cross-localization of format strings

[Christopher Schultz (JIRA)]

DateTool can be improved to allow cross-localization of format strings
--

 Key: VELTOOLS-144
 URL: https://issues.apache.org/jira/browse/VELTOOLS-144
 Project: Velocity Tools
  Issue Type: New Feature
  Components: GenericTools
Affects Versions: 2.0
 Environment: All VELTOOLS versions
Reporter: Christopher Schultz
Priority: Minor


I thought I had reported this earlier, but evidently not.

We use SimpleDateFormat patterns (which are always specified in English-style 
-MM-dd form) all over our application and we'd like to be able to display 
those patterns in a locale-sensitive way (for instance -MM-jj in the FR 
locale). DateTool is in a nice position to be able to do this conversion for 
us, since it wraps a SimpleDateFormat object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-144) DateTool can be improved to allow cross-localization of format strings

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-144.
--

   Resolution: Fixed
Fix Version/s: 2.0.x

Fixed in r1149273.

Added DateTool.toLocalizedString(String pattern, Locale locale) method.

 DateTool can be improved to allow cross-localization of format strings
 --

 Key: VELTOOLS-144
 URL: https://issues.apache.org/jira/browse/VELTOOLS-144
 Project: Velocity Tools
  Issue Type: New Feature
  Components: GenericTools
Affects Versions: 2.0
 Environment: All VELTOOLS versions
Reporter: Christopher Schultz
Priority: Minor
 Fix For: 2.0.x


 I thought I had reported this earlier, but evidently not.
 We use SimpleDateFormat patterns (which are always specified in English-style 
 -MM-dd form) all over our application and we'd like to be able to display 
 those patterns in a locale-sensitive way (for instance -MM-jj in the FR 
 locale). DateTool is in a nice position to be able to do this conversion for 
 us, since it wraps a SimpleDateFormat object.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

ClassUtils.getResource and friends

[Christopher Schultz]

All,

In a somewhat unrelated thread on the user's list, Nathan and I have
been discussing changing the ClassUtils.getResource method from calling
(in order):

  Thread.currentThread.getContextClassLoader().getResource()
  ClassUtils.class.getResource()
  callingObject.getClass().getResource()

This is the current code in that method:

1 public static URL getResource(String name, Object caller)
2 {
3 URL url = getThreadContextLoader().getResource(name);
4 if (url == null)
5 {
6 url = getClassLoader().getResource(name);
7 if (url == null)
8 {
9 url = ClassUtils.class.getResource(name);
10if (url == null  caller != null)
11{
12Class callingClass = caller.getClass();
13if (callingClass == Class.class)
14{
15callingClass = (Class)caller;
16}
17url = callingClass.getResource(name);
18}
19}
20}
21return url;
22}

I will be removing lines 6-8 and 19 because calling Class.getResource is
the same as calling Class.getClassLoader.getResource.

I was wondering about the additional work of calling
callingClass.getClass() and then re-setting callingClass to caller
which is a java.lang.Class. I'm pretty sure if caller is already a
java.lang.Class, then the getClass method will just return this, so
there's no real good reason to re-check the object, cast the caller
reference to java.lang.Class and re-set the callingClass local.

Maybe something is going on that I don't understand. Before I simplify
this code, I wanted to make sure that nobody had a specific reason for
performing this awkward manipulation of object references. If the idea
was to avoid a method call in favor of an instanceof and then checkcast
operation, I'm not sure there's any savings, there: you should just
write the code in a straightforward way so bugs don't creep-in.

If anyone has any thoughts, please let me know. Otherwise, I'll be
reducing the complexity of this code.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[jira] [Created] (VELTOOLS-145) StrutsLinkTool is not a drop-in replacement for previous versions because it extends view.LinkTool instead of view.tools.LinkTool

[Christopher Schultz (JIRA)]

StrutsLinkTool is not a drop-in replacement for previous versions because it 
extends view.LinkTool instead of view.tools.LinkTool
-

 Key: VELTOOLS-145
 URL: https://issues.apache.org/jira/browse/VELTOOLS-145
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
 Environment: Velocity Tools 2.0
Reporter: Christopher Schultz


StrutsLinkTool's parent class has been changed to be o.a.v.t.view.LinkTool, 
which is the preferred LinkTool to use. That new class has many methods (such 
as setRelative) removed but that remain in the old class (in the 
o.a.v.t.view.tools package).

StrutsLinkTool should inherit from the deprecated version of LinkTool in order 
to maintain API compatibility with 1.4 and prior releases.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Resolved] (VELTOOLS-145) StrutsLinkTool is not a drop-in replacement for previous versions because it extends view.LinkTool instead of view.tools.LinkTool

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELTOOLS-145.
--

   Resolution: Fixed
Fix Version/s: 2.0.x

Fixed in r1149367.

 StrutsLinkTool is not a drop-in replacement for previous versions because it 
 extends view.LinkTool instead of view.tools.LinkTool
 -

 Key: VELTOOLS-145
 URL: https://issues.apache.org/jira/browse/VELTOOLS-145
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 2.0
 Environment: Velocity Tools 2.0
Reporter: Christopher Schultz
 Fix For: 2.0.x


 StrutsLinkTool's parent class has been changed to be o.a.v.t.view.LinkTool, 
 which is the preferred LinkTool to use. That new class has many methods (such 
 as setRelative) removed but that remain in the old class (in the 
 o.a.v.t.view.tools package).
 StrutsLinkTool should inherit from the deprecated version of LinkTool in 
 order to maintain API compatibility with 1.4 and prior releases.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Created] (VELTOOLS-143) LinkTool.setURI does not allow mailto: links to have parameters added usign param() method

[Christopher Schultz (JIRA)]

LinkTool.setURI does not allow mailto: links to have parameters added usign 
param() method
--

 Key: VELTOOLS-143
 URL: https://issues.apache.org/jira/browse/VELTOOLS-143
 Project: Velocity Tools
  Issue Type: Bug
  Components: GenericTools
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity Tools 2.0
Reporter: Christopher Schultz
Priority: Minor


This worked in Velocity Tools 1.4.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Updated] (VELTOOLS-143) LinkTool.uri() causes mailto: links to ignore parameters added using param() method

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELTOOLS-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz updated VELTOOLS-143:
-

Summary: LinkTool.uri() causes mailto: links to ignore parameters added 
using param() method  (was: LinkTool.setURI does not allow mailto: links to 
have parameters added usign param() method)

 LinkTool.uri() causes mailto: links to ignore parameters added using param() 
 method
 ---

 Key: VELTOOLS-143
 URL: https://issues.apache.org/jira/browse/VELTOOLS-143
 Project: Velocity Tools
  Issue Type: Bug
  Components: GenericTools
Affects Versions: 2.0
 Environment: Velocity 1.7, Velocity Tools 2.0
Reporter: Christopher Schultz
Priority: Minor

 This worked in Velocity Tools 1.4.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELOCITY-801) Velocity 1.7 uses string interning

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032077#comment-13032077
 ] 

Christopher Schultz commented on VELOCITY-801:
--

This is a relatively easy fix if String.intern is proven to be holding onto 
these references inappropriately for some reason: just provide a simple, local 
String interning mechanism that can be discarded when the instance of (for 
instance) the Velocity object is discarded.

I'm actually glad to see Velocity is interning strings, though :)


 Velocity 1.7 uses string interning
 --

 Key: VELOCITY-801
 URL: https://issues.apache.org/jira/browse/VELOCITY-801
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7.x
 Environment: n.a.
Reporter: Alexander Veit
Priority: Critical

 String interning consumes memory that cannot be reclaimed by the java runtime 
 even if the velocity runtime singleton is being discarded.
 This is an issue for server applications that use Velocity (e.g. we have a 
 software product that may use tens of thousands of Velocity files to create 
 content dynamically).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] [Commented] (VELOCITY-801) Velocity 1.7 uses string interning

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032081#comment-13032081
 ] 

Christopher Schultz commented on VELOCITY-801:
--

Alexander, one more comment:

If you are concerned about memory usage, consider /not/ using the singleton 
Velocity object. Instead, instantiate your own and then you always have the 
option of discarding it. If you use the singleton pattern that Velocity 
supports, you're right: the singleton will never be collected. Take control of 
your own objects and stop using the singleton. It will give you greater 
flexibility.

 Velocity 1.7 uses string interning
 --

 Key: VELOCITY-801
 URL: https://issues.apache.org/jira/browse/VELOCITY-801
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7.x
 Environment: n.a.
Reporter: Alexander Veit
Priority: Critical

 String interning consumes memory that cannot be reclaimed by the java runtime 
 even if the velocity runtime singleton is being discarded.
 This is an issue for server applications that use Velocity (e.g. we have a 
 software product that may use tens of thousands of Velocity files to create 
 content dynamically).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELTOOLS-103) ImportSupport really needs a unit test

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980754#action_12980754
 ] 

Christopher Schultz commented on VELTOOLS-103:
--

Since it's already hosted on sourceforge, I think I'll leave it there for the 
time being.

I should figure out how to mavenize it, though. Can you help me with that 
off-line?

 ImportSupport really needs a unit test
 --

 Key: VELTOOLS-103
 URL: https://issues.apache.org/jira/browse/VELTOOLS-103
 Project: Velocity Tools
  Issue Type: Test
  Components: Test
Affects Versions: 1.4, 2.0, 2.x
 Environment: All
Reporter: Christopher Schultz
Priority: Minor
 Attachments: VELTOOLS-103.zip


 ImportSupport needs a unit test.
 I wrote one a while ago, but it depends upon a (small) library that I wrote. 
 I have since released that library under the Apache License V2.0 on 
 SourceForge.net (http://sourceforge.net/projects/tuc). If the team is okay 
 with including this library as a test-time dependency, I can submit a working 
 unit test very quickly (just have to update it to 2.0-standards, if anything).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Upgrading ASF Jira to 4.2.x [rant]

[Christopher Schultz]

Antonio,

On 1/10/2011 11:25 AM, Antonio Petrelli wrote:
 2011/1/10 Christopher Schultz ch...@christopherschultz.net:
 First, JIRA was always painfully slow and would never remember a
 password I chose -- I had to reset it every time I wanted to use it.
 
 So you are complaining that Jira would not send you the password that
 you forgot?
 It's for your safety, you know.

No. I'm complaining that no matter how many times I reset my password,
JIRA wouldn't remember it. I wasn't mis-typing it: I use KeePass to
manage the password and do a drag-and-drop password entry for both
changing my password and for authenticating. JIRA just choked all the
time. Maybe it was a password-length restriction (which is kind of
foolish these days) or some other thing where the password I entered
when changing it wasn't the one recorded -- or alternatively that the
password I used for authentication wasn't processed in the same way,
which is essentially the same thing: fail.

 Also, simple things
 like commenting and changing bug information was awkward compared to
 Bugzilla.
 
 Oh well, I notice that you are a Bugzilla fan, and I am a Bugzilla
 hater, I can say the exact thing swapping the terms of comparison.

Fair enough: I should complain directly to the JIRA folks that having to
scroll to the top of the page to click the COMMENT link just to go
back down to the bottom to attach a comment is kind of silly.

 Now, I've only logged-in and seen the front page and already I'm not
 liking it: the page was blank except for empty titled-sections (with
 empty titles!) and then everything filled-in slowly over a period of
 about 10 seconds. Woo hoo! Javascript and Web 2.0... just what JIRA
 needed: a way to go slower.
 
 I think the problem might be the browser, i am on a pretty-old Pentium
 D with Chrome it goes pretty fast.

JIRA is painfully slow on any hardware I've used. I don't know if it's
the server's fault, JIRA's fault, or Java's fault. I just know that my
browser accessing Java-based webapps on my productions servers are nice
and snappy and that JIRA has always been slow as a dog.

Since all the Javascript has been added, the page load time is faster
(the blank page loads with nothing but JIRA chrome somewhat quickly) but
then you have to sit twiddling your thumbs for all the content to arrive
after the fact.

-chris



signature.asc
Description: OpenPGP digital signature

[jira] Commented: (VELTOOLS-103) ImportSupport really needs a unit test

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELTOOLS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980355#action_12980355
 ] 

Christopher Schultz commented on VELTOOLS-103:
--

Sure, I can make this into a patch, though it's just two entirely new files.

My library is not available through Maven, though I'd be happy to learn enough 
Maven to tag it properly and shove it into a repo somewhere.

As for extras, I could certainly move the project there as well: should I 
attach it to an existing project label, or create a new one? It's not exactly 
tied to Velocity or Tomcat or any other existing Apache project. It's not 
entirely clear how the apache-extras site is supposed to be used, and the FAQ 
is a broken link :(

 ImportSupport really needs a unit test
 --

 Key: VELTOOLS-103
 URL: https://issues.apache.org/jira/browse/VELTOOLS-103
 Project: Velocity Tools
  Issue Type: Test
  Components: Test
Affects Versions: 1.4, 2.0, 2.x
 Environment: All
Reporter: Christopher Schultz
Priority: Minor
 Attachments: VELTOOLS-103.zip


 ImportSupport needs a unit test.
 I wrote one a while ago, but it depends upon a (small) library that I wrote. 
 I have since released that library under the Apache License V2.0 on 
 SourceForge.net (http://sourceforge.net/projects/tuc). If the team is okay 
 with including this library as a test-time dependency, I can submit a working 
 unit test very quickly (just have to update it to 2.0-standards, if anything).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

RE: Upgrading ASF Jira to 4.2.x [rant]

[Christopher Schultz]

All,

I have only just logged-into the test instance of the new JIRA and, I
have to admit, I wasn't sure how the JIRA team could make the product worse.

First, JIRA was always painfully slow and would never remember a
password I chose -- I had to reset it every time I wanted to use it. I
gave up and started using the auto-generated temp passwords it was
sending to me and never setting a real password. Also, simple things
like commenting and changing bug information was awkward compared to
Bugzilla.

Now, I've only logged-in and seen the front page and already I'm not
liking it: the page was blank except for empty titled-sections (with
empty titles!) and then everything filled-in slowly over a period of
about 10 seconds. Woo hoo! Javascript and Web 2.0... just what JIRA
needed: a way to go slower.

:(

-chris



signature.asc
Description: OpenPGP digital signature

[jira] Resolved: (VELOCITY-794) can't get the velocity template in networks

[Christopher Schultz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VELOCITY-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Schultz resolved VELOCITY-794.
--

Resolution: Duplicate

Duplicate of VELTOOLS-782

 can't get the velocity template in networks 
 

 Key: VELOCITY-794
 URL: https://issues.apache.org/jira/browse/VELOCITY-794
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.7
 Environment: windows xp
 eclipse 3.5
Reporter: fanglei

begin:
   properties.setProperty(Velocity.FILE_RESOURCE_LOADER_PATH, 
 FileParentPath);   
   velocityEngine = new VelocityEngine(properties);
  when I get VM Template in this way:
   template = velocityEngine.getTemplate(C:\xxx\ABC.vm 
 GBK);
  I can get the template object.
 but when I get VM Template which the path on LAN like this:
template = 
 velocityEngine.getTemplate(\\CompanyName\myPC\xxx\ABC.vm GBK);
 I can't get the template object and catch an error message:
 2011-1-7 11:47:00 org.apache.velocity.runtime.log.JdkLogChute log
 严重: ResourceManager : unable to find resource 
 'TB_%modelNameInFileName%.java.vm' in any resource loader.
 org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
 resource 'TB_%modelNameInFileName%.java.vm'
   at 
 org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:483)
   at 
 org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:354)
   at 
 org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1400)
   at 
 org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:422)
   at mda.codemachine.core.engine.Builder.build(Builder.java:50)
 I want create VM LAN Pool for public,so I must do this.
 thank you~


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-782) UNC Path support for Velocity

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978533#action_12978533
 ] 

Christopher Schultz commented on VELOCITY-782:
--

Shouldn't there be some back-slashes in your UNC path name? I don't see any of 
them.

 UNC Path support for Velocity
 -

 Key: VELOCITY-782
 URL: https://issues.apache.org/jira/browse/VELOCITY-782
 Project: Velocity
  Issue Type: Bug
 Environment: Jameica 1.10 + Hibiscus 1.12
 Windows 7 Ultimate x64
 WHS
Reporter: Frank Glaser
Priority: Minor
 Attachments: patch1-0


 Add UNC Path support for the getTemplate function:
 Here an extract of the Hibiscus log file:
 ...
 [Mon Oct 18 18:23:16 CEST 
 2010][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor.check]
  creating progress monitor for GUI
 [Mon Oct 18 18:23:16 CEST 
 2010][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor$2.run]
  activating progress monitor
 [Mon Oct 18 18:23:16 CEST 2010][INFO][de.willuhn.boot.BootLoader.resolve]   
 init service de.willuhn.jameica.services.VelocityService
 [Mon Oct 18 18:23:16 CEST 2010][INFO][de.willuhn.boot.BootLoader.resolve] 
 used time to init de.willuhn.jameica.services.VelocityService: 285 millis
 [Mon Oct 18 18:23:16 CEST 
 2010][ERROR][de.willuhn.jameica.services.VelocityService$VelocityLogger.log] 
 ResourceManager : unable to find resource 
 'de.willuhn.jameica.hbci.rmi.Umsatz.csv.vm' in any resource loader.
 [Mon Oct 18 18:23:16 CEST 
 2010][ERROR][de.willuhn.jameica.hbci.io.VelocityExporter.doExport] error 
 while writing into export file
 org.apache.velocity.exception.ResourceNotFoundException: Unable to find 
 resource 'de.willuhn.jameica.hbci.rmi.Umsatz.csv.vm'
   at 
 org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(ResourceManagerImpl.java:452)
   at 
 org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(ResourceManagerImpl.java:335)
   at 
 org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1102)
   at 
 org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:549)
   at 
 de.willuhn.jameica.hbci.io.VelocityExporter.doExport(VelocityExporter.java:107)
   at 
 de.willuhn.jameica.hbci.gui.dialogs.ExportDialog$3.run(ExportDialog.java:193)
   at de.willuhn.jameica.gui.GUI$6.run(GUI.java:912)
 [Mon Oct 18 18:23:16 CEST 
 2010][ERROR][de.willuhn.jameica.messaging.LogMessageConsumer.handleMessage] 
 Fehler beim Schreiben in die Export-Datei
 ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-599) DataSourceResourceLoader doesn't support UTF8

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12978540#action_12978540
 ] 

Christopher Schultz commented on VELOCITY-599:
--

Mark's hack could waste huge amounts of memory due to the complete fetching of 
the clob, then converting it to a byte array, then reading from that.

I'm not sure why using getBinaryStream doesn't work. Can someone explain? Using 
getClob sounds like it's just going to make us convert from char to binary and 
then back again at a higher level.

I'll make another push to change template fetching to use Readers. Maybe in 2.0?

 DataSourceResourceLoader doesn't support UTF8
 -

 Key: VELOCITY-599
 URL: https://issues.apache.org/jira/browse/VELOCITY-599
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.5
 Environment: WindowsServer2003 R2, 
 Oracle10g(10.2.0,UTF8characterSet),  jdk1.5.0_12
Reporter: markchen
 Fix For: 2.x


 If templates are stored in the database instead of files,the characters 
 retrived becomes garbled.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Created: (VELOCITY-793) Change ResourceLoader.getResourceStream to getResourceReader

[Christopher Schultz (JIRA)]

Change ResourceLoader.getResourceStream to getResourceReader


 Key: VELOCITY-793
 URL: https://issues.apache.org/jira/browse/VELOCITY-793
 Project: Velocity
  Issue Type: Wish
  Components: Engine
Reporter: Christopher Schultz
 Fix For: 2.x


It would be nice to use Readers instead of InputStreams for templates.

Velocity is all about text-based rendering, so the templates are certainly 
going to be text-based. Using a Reader allows individual readers to determine 
the character encoding if necessary (say, from a database) and not have another 
component second-guess them.

Of course, this is a serious change to the API. We could possible re-implement 
getResourceStream to read a Reader and provide bytes as backward-compatibility 
with older client code, but since we're going to 2.0, this would be the time to 
make breaking changes to the API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [tools] Ideas about future Velocity Tools features

[Christopher Schultz]

Antonio,

On 12/10/2010 3:43 AM, Antonio Petrelli wrote:
 Who used DisplayTag knows what I
 mean: a tag library that manages sorting and pagination (internal and
 external), alternate coloring etc. IOW, all the aspects of a table of
 results that you might imagine.

I've developed what I think is a great Velocimacro that acts as a pager.
116 lines including comments, debug output, etc. I'd be happy to share
it with the community... I'd probably get feedback about how it could be
improved :)

The AlternatorTool does a great job for alternate coloring.

Does DisplayTag do anything on top of those, or is the idea that it's
all rolled into one tag so you don't have to piece-together your solution?

-chris



signature.asc
Description: OpenPGP digital signature

[jira] Commented: (VELOCITY-761) Can not reference a property declared in a super-interface and implemented in a non-public class

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12914523#action_12914523
 ] 

Christopher Schultz commented on VELOCITY-761:
--

William, it's hard to tell why data wasn't available... it might not actually 
be possible to give an error message that is as specific as type is not 
visible.

 Can not reference a property declared in a super-interface and implemented in 
 a non-public class
 

 Key: VELOCITY-761
 URL: https://issues.apache.org/jira/browse/VELOCITY-761
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6.3
Reporter: Charles Miller

 Consider the following:
 public interface MyUser extends java.security.Principal { 
  String getEmailAddress();
  }
 class MyUserImpl implements MyUser {
 public String getName() { ... }
 public String getEmailAddress() { ... }
 }
 If I put a MyUserImpl in my Velocity context, $user.emailAddress will 
 resolve, but $user.name will not.
 This is a problem with ClassMap#createMethodCache(). It ignores methods 
 declared on the MyUserImpl class because the class is non-public, and it only 
 looks up one level in the Interface hierarchy for methods defined on 
 interfaces: so it will go up as far as the MyUser interface but not as far as 
 the Principal interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-774) Provide #unset directive

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910872#action_12910872
 ] 

Christopher Schultz commented on VELOCITY-774:
--

You can also do

#set($foo = false)

...which I believe has the same effect. I use this at the bottom of loops all 
the time to make sure that I don't get in-loop variables bleeding-over one loop 
iteration into the next.

 Provide #unset directive
 

 Key: VELOCITY-774
 URL: https://issues.apache.org/jira/browse/VELOCITY-774
 Project: Velocity
  Issue Type: New Feature
  Components: Engine
Affects Versions: 1.7-beta1
Reporter: Michael Osipov

 Sometimes one wants to use a variable in a certain scope because the further 
 existence might lead to errors. I declared var with #set should be 
 unsettable. See VELOCITY-773 for a iuse case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-773) Provide locally scoped #set variables

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910874#action_12910874
 ] 

Christopher Schultz commented on VELOCITY-773:
--

What implications does this have for code like this:

#foreach($foo in $foos)
  #set($foreach.someVar = 'some value')
  #foreach($bar in $bars)
.. terribly interesting stuff
  #end

  $foreach.someVar
#end

Does each foreach loop create a nested Context in which vars are defined and 
then cleared? Otherwise, the behavior of nested foreach loops might surprise 
some people.

 Provide locally scoped #set variables
 -

 Key: VELOCITY-773
 URL: https://issues.apache.org/jira/browse/VELOCITY-773
 Project: Velocity
  Issue Type: Improvement
  Components: Engine
Affects Versions: 1.7-beta1
Reporter: Michael Osipov

 Consider this snippet:
 !-- Generated pushbutton groups --
 #foreach ($group in $form.pushbuttonGroups)
 div class=die-button-group style=#coordinates($group)
 #**##foreach ($groupChild in $group.children)
 #**##if (!$velocityHasNext)#set($turnPaddingOff = 
 'style=padding-bottom: 0px;')#end
 #**##if ($groupChild.class.simpleName == Pushbutton)
   #*  *#div $!turnPaddingOff
   #*  *#button type=submit name=$groupChild.name 
 value=$groupChild.value 
 onclick=loadSubsequent()#label($groupChild.label)/button
   
   #*  *#/div
 #**##end
 #**##end
 /div
 #end
 There is an inherent bug. After the first run of the outer foreach, the var 
 turnPaddingOff is still available and will always set in the div tag. There 
 is only one workaround. At the end of the outer foreach you have to set it to 
 ''.
 #set should be available as a locally scoped thing in #foreach or other 
 constructs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-761) Can not reference a property declared in a super-interface and implemented in a non-public class

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910876#action_12910876
 ] 

Christopher Schultz commented on VELOCITY-761:
--

William, you didn't answer my question: which method are you trying to call? 
get(int) should be accessible while get(String) should not be.

 Can not reference a property declared in a super-interface and implemented in 
 a non-public class
 

 Key: VELOCITY-761
 URL: https://issues.apache.org/jira/browse/VELOCITY-761
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6.3
Reporter: Charles Miller

 Consider the following:
 public interface MyUser extends java.security.Principal { 
  String getEmailAddress();
  }
 class MyUserImpl implements MyUser {
 public String getName() { ... }
 public String getEmailAddress() { ... }
 }
 If I put a MyUserImpl in my Velocity context, $user.emailAddress will 
 resolve, but $user.name will not.
 This is a problem with ClassMap#createMethodCache(). It ignores methods 
 declared on the MyUserImpl class because the class is non-public, and it only 
 looks up one level in the Interface hierarchy for methods defined on 
 interfaces: so it will go up as far as the MyUser interface but not as far as 
 the Principal interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Problems with svn

[Christopher Schultz]

Antonio,

On 7/30/2010 3:34 AM, Antonio Petrelli wrote:
 2010/7/29 Christopher Schultz ch...@christopherschultz.net:
 svn reports this version:
 $ svn --version
 svn, version 1.5.1 (r32289)
   compiled Aug  6 2009, 20:47:37
 
 You must use Subversion 1.6.x

Hmm... Debian Lenny says I'm all up-to-date. Any idea if subversion 1.6
is in testing or even unstable? It looks like 1.6.12 is available from
lenny-backports, but I know very little about Debian administration. Can
someone give me a few pointers if they happen to know?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: Problems with svn

[Christopher Schultz]

All,

On 7/30/2010 10:40 AM, Christopher Schultz wrote:
 Can someone give me a few pointers if they happen to know?

Nevermind, I've got it working through lenny-backports: svn update works
just fine, now.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Problems with svn

[Christopher Schultz]

All,

After a long hiatus, today, I tried to do an svn update and I got this
message:

~/projects/velocity/tools/trunk$ svn update
svn: This client is too old to work with working copy '.'.  You need
to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

svn reports this version:
$ svn --version
svn, version 1.5.1 (r32289)
   compiled Aug  6 2009, 20:47:37

I thought maybe I was just stuck in a bad place, so I tried to get a new
copy of the source directly from the Apache web site:

http://velocity.apache.org/tools/devel/index.html#Subversion_Repository

$ svn checkout http://svn.apache.org/viewcvs.cgi/velocity/tools/trunk/
svn: Repository moved temporarily to
'http://svn.apache.org/viewvc/velocity/tools/trunk'; please relocate

Uh, okay. How about:

$ svn checkout http://svn.apache.org/viewvc/velocity/tools/trunk/
svn: Repository moved permanently to '/viewvc/velocity/tools/trunk/';
please relocate

I'm not sure what to do at this point.

Any suggestions?

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

[jira] Created: (VELTOOLS-126) XSS Vulnerability when using struts/ErrorsTool.getMsgs

[Christopher Schultz (JIRA)]

XSS Vulnerability when using struts/ErrorsTool.getMsgs
--

 Key: VELTOOLS-126
 URL: https://issues.apache.org/jira/browse/VELTOOLS-126
 Project: Velocity Tools
  Issue Type: Bug
  Components: VelocityStruts
Affects Versions: 1.4, 2.x
 Environment: Identified in velocity-tools 1.4, verified by reading 
code in trunk.
Reporter: Christopher Schultz


The code for ErrorsTool.getMsgs goes roughly like this:

String message = message(errors.header);

foreach(error) {
  message += message(errors.prefix) + error + message(errors.suffix)

message += message(errors.footer)

return message;

This is easily open to an XSS attack when an error message contains user input.

Honestly, I'm not entirely sure if we should even do anything about this, 
because the ErrorsTool is not strictly for use in an HTML context, so escaping 
the error message itself may not be appropriate. Also, the message itself may 
contain markup which the developer wants to remain, while the user input should 
be escaped.

It's possible that the solution to this problem is to put a big warning on the 
tool that XSS attacks are very easy using this tool.

I've been running with it for years, and didn't notice until today. I replaced 
my use of errors.getMsgs with this:

$!msg.errors.header
#foreach($error in $errors.get($fieldName))
$!msg.errors.prefix#htmlEscape($error)$!msg.errors.suffix
#end
$!msg.errors.header

...which is appropriate for my uses, but might not work for everyone.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

[jira] Commented: (VELOCITY-761) Can not reference a property declared in a super-interface and implemented in a non-public class

[Christopher Schultz (JIRA)]

[ 
https://issues.apache.org/jira/browse/VELOCITY-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12893880#action_12893880
 ] 

Christopher Schultz commented on VELOCITY-761:
--

William,

Which get method are you trying to call? There are two:

public String get(String key) // defined in package-protected class MapList
public Object get(int index) // defined in public interface java.util.List

I think you probably can't access your get(String) method, since it's not 
actually visible publicly. This seems perfectly reasonable to me, since the 
list of accessible methods should be:

* all public methods from public interfaces
+
* all public methods from public classes

You'll just have to modify your class structure or visibility in order to make 
this method callable from Velocity.

 Can not reference a property declared in a super-interface and implemented in 
 a non-public class
 

 Key: VELOCITY-761
 URL: https://issues.apache.org/jira/browse/VELOCITY-761
 Project: Velocity
  Issue Type: Bug
  Components: Engine
Affects Versions: 1.6.3
Reporter: Charles Miller

 Consider the following:
 public interface MyUser extends java.security.Principal { 
  String getEmailAddress();
  }
 class MyUserImpl implements MyUser {
 public String getName() { ... }
 public String getEmailAddress() { ... }
 }
 If I put a MyUserImpl in my Velocity context, $user.emailAddress will 
 resolve, but $user.name will not.
 This is a problem with ClassMap#createMethodCache(). It ignores methods 
 declared on the MyUserImpl class because the class is non-public, and it only 
 looks up one level in the Interface hierarchy for methods defined on 
 interfaces: so it will go up as far as the MyUser interface but not as far as 
 the Principal interface.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: [tools] Adding localization method to DateTool

[Christopher Schultz]

Nathan,

Resurrecting this because I'm ready to commit.

On 10/29/2009 3:04 PM, Nathan Bubna wrote:
 On Thu, Oct 29, 2009 at 8:06 AM, Christopher Schultz
 ch...@christopherschultz.net wrote:
 Nathan,

 On 10/29/2009 11:02 AM, Christopher Schultz wrote:
 I like re-coding into SimpleDataFormat better.

 D'oh: that's not possible because DateFormat doesn't expose the pattern
 it's using, so I'll have to return something unrelated. Hmm. I'm not a
 big fan of NULL but it's also not exactly consistent with the API if an
 error message is returned.

 Any ideas other than NULL?
 
 Not really, because a) it's unlikely to ever occur in practice and b)
 that's the traditional VelocityTools response to bad inputs.  If you
 call $date.toLocalizedPattern($invalidInput) then that's little better
 than $date.noSuchMethod($validinput).  Either way, part of the
 reference is invalid, and we want to render it as an invalid
 reference.  Returning null accomplishes that.

While I agree that VelocityTools' traditional response to bad input is
null, the problem here isn't the user's bad input: instead, it's our
reliance on an unpublished but highly likely coincidence that DateFormat
always hands-out SimpleDateFormat objects.

For patterns other than simple_date and stuff like that, I could
simply construct a new SimpleDateFormat object and use that, but then
the behavior of toLocalizedPattern would differ from the other methods
-- that is, short_date would work, except when it doesn't :(

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature