[jira] [Created] (VELOCITY-878) commons collections is required at run time

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

[jira] [Created] (VELOCITY-878) commons collections is required at run time

JIRA jira@apache.org
Mary Helm created VELOCITY-878:
----------------------------------

             Summary: commons collections is required at run time
                 Key: VELOCITY-878
                 URL: https://issues.apache.org/jira/browse/VELOCITY-878
             Project: Velocity
          Issue Type: Bug
          Components: Engine
    Affects Versions: 2.0
            Reporter: Mary Helm


The Velocity upgrading page states that •commons-lang, commons-collections and commons-logging aren't needed any more at runtime.
However, commons collections is still required.  Here is the error received when using the latese version (4.1) of commons-collections jar:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties
        at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
        at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
...
...
Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.ExtendedProperties
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
 



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Created] (VELOCITY-878) commons collections is required at run time

Claude Brisson-2
Our first 2.0 JIRA entry! Champagne!


On 08/12/2016 17:38, Mary Helm (JIRA) wrote:

> Mary Helm created VELOCITY-878:
> ----------------------------------
>
>               Summary: commons collections is required at run time
>                   Key: VELOCITY-878
>                   URL: https://issues.apache.org/jira/browse/VELOCITY-878
>               Project: Velocity
>            Issue Type: Bug
>            Components: Engine
>      Affects Versions: 2.0
>              Reporter: Mary Helm
>
>
> The Velocity upgrading page states that •commons-lang, commons-collections and commons-logging aren't needed any more at runtime.
> However, commons collections is still required.  Here is the error received when using the latese version (4.1) of commons-collections jar:
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties
> at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
> at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
> ...
> ...
> Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.ExtendedProperties
> at java.net.URLClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
>  
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Created] (VELOCITY-878) commons collections is required at run time

Claude Brisson-2
This issue has revealed another problem: we still have deprecated
initialization methods taking an ExtendedProperties object. But I had
totally overlooked the fact that since we now use shading, the method
signatures will change anyway. Even if we avoid shading this one
specific class, we can't decently keep an undeclared dependency, even
for backward compatibility.

To upgrade, frameworks using this setExtendedProperties method just have
to use it with our cloned class, o.a.v.util.ExtProperties.

Plus, getting rid of ExtendedProperties can allow us to upgrade our
dependency to commons-collections v4.1.

   Claude

On 08/12/2016 19:10, Claude Brisson wrote:

> Our first 2.0 JIRA entry! Champagne!
>
>
> On 08/12/2016 17:38, Mary Helm (JIRA) wrote:
>> Mary Helm created VELOCITY-878:
>> ----------------------------------
>>
>>               Summary: commons collections is required at run time
>>                   Key: VELOCITY-878
>>                   URL:
>> https://issues.apache.org/jira/browse/VELOCITY-878
>>               Project: Velocity
>>            Issue Type: Bug
>>            Components: Engine
>>      Affects Versions: 2.0
>>              Reporter: Mary Helm
>>
>>
>> The Velocity upgrading page states that •commons-lang,
>> commons-collections and commons-logging aren't needed any more at
>> runtime.
>> However, commons collections is still required.  Here is the error
>> received when using the latese version (4.1) of commons-collections jar:
>> Exception in thread "main" java.lang.NoClassDefFoundError:
>> org/apache/commons/collections/ExtendedProperties
>>     at
>> org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
>>     at
>> org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
>> ...
>> ...
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.commons.collections.ExtendedProperties
>>     at java.net.URLClassLoader.findClass(Unknown Source)
>>     at java.lang.ClassLoader.loadClass(Unknown Source)
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Created] (VELOCITY-878) commons collections is required at run time

Claude Brisson-2

> Plus, getting rid of ExtendedProperties can allow us to upgrade our
> dependency to commons-collections v4.1.
>
hum.. to totally get rid of this dependency, in fact.

   Claude


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Created] (VELOCITY-878) commons collections is required at run time

Michael Osipov
In reply to this post by Claude Brisson-2
Am 2016-12-09 um 13:05 schrieb Claude Brisson:
> This issue has revealed another problem: we still have deprecated
> initialization methods taking an ExtendedProperties object. But I had
> totally overlooked the fact that since we now use shading, the method
> signatures will change anyway. Even if we avoid shading this one
> specific class, we can't decently keep an undeclared dependency, even

I'd even question wether ExtProperties is needed as public API at all.
ExtendedProperties was written long time ago, while Properties still
don't have many features, it satisfies many cases.

Why not have the user provide Properties only and ExtPropeties will
extend Properties, removing duplication, adding only necessary bits and
be an implementation-specific detail (e.g., VelocityProperties).

The user pretty much does not care how velocity internally works with
properties.

Does this make sense?

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] [Created] (VELOCITY-878) commons collections is required at run time

Claude Brisson-2
I agree, we don't need to expose ExtProperties.


On 09/12/2016 17:07, Michael Osipov wrote:

> Am 2016-12-09 um 13:05 schrieb Claude Brisson:
>> This issue has revealed another problem: we still have deprecated
>> initialization methods taking an ExtendedProperties object. But I had
>> totally overlooked the fact that since we now use shading, the method
>> signatures will change anyway. Even if we avoid shading this one
>> specific class, we can't decently keep an undeclared dependency, even
>
> I'd even question wether ExtProperties is needed as public API at all.
> ExtendedProperties was written long time ago, while Properties still
> don't have many features, it satisfies many cases.
>
> Why not have the user provide Properties only and ExtPropeties will
> extend Properties, removing duplication, adding only necessary bits
> and be an implementation-specific detail (e.g., VelocityProperties).
>
> The user pretty much does not care how velocity internally works with
> properties.
>
> Does this make sense?
>
> Michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]