You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Nathan Bubna <nb...@gmail.com> on 2008/09/05 20:13:03 UTC
gump failures, please help
ok. after weeks of wrestling with gump to find out what the failures
are about, this last build gave some decent info.
See:
http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/gump_work/build_velocity-engine_velocity-engine-test.html
I think this section shows the main problem:
[junit] log: [debug] Velocity was not initialized! Calling init()...
[junit] [debug] Starting Apache Velocity v03092008 (compiled:
2008-09-03 18:37:33)
[junit] [debug] Default Properties File:
org/apache/velocity/runtime/defaults/velocity.properties
[junit] [debug] ResourceManager : No configuration information
for resource loader named 'string'. Skipping.
[junit] [debug] ResourceLoader instantiated:
org.apache.velocity.runtime.resource.loader.FileResourceLoader
[junit] [debug] Do unicode file recognition: false
[junit] [debug] FileResourceLoader : adding path
'/srv/gump/public/workspace/velocity-engine/test/resourceexists'
[junit] [debug] ResourceCache: initialized (class
org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
java.util.Collections$SynchronizedMap cache map.
As you can see, the engine knows there are two resource loaders 'file'
and 'string'. It has path info for the 'file' resource loader, but it
has *no* info on the 'string' resource loader. But if you look at the
test case, it clearly adds info for both loaders:
velocity = new VelocityEngine();
velocity.setProperty("resource.loader", "file,string");
velocity.setProperty("file.resource.loader.path", path);
velocity.setProperty("string.resource.loader.class",
StringResourceLoader.class.getName());
This code runs perfectly on my machine and probably on yours too. So,
what the hell? If you further peruse the output from the last gump
build (link above), you will see that the ResourceInstanceTestCase has
the same problem (no info for the 'testrl' resource loader).
The ResourceManager code producing that 'no config info' log message is:
String loaderName = (String) it.next();
StringBuffer loaderID = new StringBuffer(loaderName);
loaderID.append(".").append(RuntimeConstants.RESOURCE_LOADER);
ExtendedProperties loaderConfiguration =
rsvc.getConfiguration().subset(loaderID.toString());
if (loaderConfiguration == null)
{
log.debug("ResourceManager : No configuration
information for resource loader named '" +
loaderName + "'. Skipping.");
continue;
}
Why this would work for 'file' and not for 'string' or 'testrl' is
currently a baffling mystery to me. My best guess at this point is
that it is due to some underlying change in Commons-Collections'
ExtendedProperties class. But that seems kind of unlikely. Any
insights? I'm about ready to give up and just find a workaround that
makes gump happy, but if there is a bug coming down the line, that
would not be helpful...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: gump failures, please help
Posted by Nathan Bubna <nb...@gmail.com>.
My suspicion has fallen on the fix done for this:
https://issues.apache.org/jira/browse/COLLECTIONS-271
which we also heard about here (for reference)
https://issues.apache.org/jira/browse/VELOCITY-567
because anything added through our setProperty method goes into an
ExtendedProperties whose values are passed into the final
ExtendedProperties via the combine() method. By circumventing the
ExtendedProperties.setProperty method in the patch for
COLLECTIONS-271, i'm thinking that the new props don't end up in
ExtendedProperties' keysAsListed array, which it uses for getKeys()
which the subset() method (and therefore, us) is entirely reliant
upon.
i'll ping the commons list....
On Fri, Sep 5, 2008 at 11:13 AM, Nathan Bubna <nb...@gmail.com> wrote:
> ok. after weeks of wrestling with gump to find out what the failures
> are about, this last build gave some decent info.
>
> See:
> http://vmgump.apache.org/gump/public/velocity-engine/velocity-engine-test/gump_work/build_velocity-engine_velocity-engine-test.html
>
> I think this section shows the main problem:
>
> [junit] log: [debug] Velocity was not initialized! Calling init()...
> [junit] [debug] Starting Apache Velocity v03092008 (compiled:
> 2008-09-03 18:37:33)
> [junit] [debug] Default Properties File:
> org/apache/velocity/runtime/defaults/velocity.properties
> [junit] [debug] ResourceManager : No configuration information
> for resource loader named 'string'. Skipping.
> [junit] [debug] ResourceLoader instantiated:
> org.apache.velocity.runtime.resource.loader.FileResourceLoader
> [junit] [debug] Do unicode file recognition: false
> [junit] [debug] FileResourceLoader : adding path
> '/srv/gump/public/workspace/velocity-engine/test/resourceexists'
> [junit] [debug] ResourceCache: initialized (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl) with class
> java.util.Collections$SynchronizedMap cache map.
>
> As you can see, the engine knows there are two resource loaders 'file'
> and 'string'. It has path info for the 'file' resource loader, but it
> has *no* info on the 'string' resource loader. But if you look at the
> test case, it clearly adds info for both loaders:
>
> velocity = new VelocityEngine();
> velocity.setProperty("resource.loader", "file,string");
> velocity.setProperty("file.resource.loader.path", path);
> velocity.setProperty("string.resource.loader.class",
> StringResourceLoader.class.getName());
>
> This code runs perfectly on my machine and probably on yours too. So,
> what the hell? If you further peruse the output from the last gump
> build (link above), you will see that the ResourceInstanceTestCase has
> the same problem (no info for the 'testrl' resource loader).
>
> The ResourceManager code producing that 'no config info' log message is:
>
> String loaderName = (String) it.next();
> StringBuffer loaderID = new StringBuffer(loaderName);
> loaderID.append(".").append(RuntimeConstants.RESOURCE_LOADER);
>
> ExtendedProperties loaderConfiguration =
> rsvc.getConfiguration().subset(loaderID.toString());
> if (loaderConfiguration == null)
> {
> log.debug("ResourceManager : No configuration
> information for resource loader named '" +
> loaderName + "'. Skipping.");
> continue;
> }
>
> Why this would work for 'file' and not for 'string' or 'testrl' is
> currently a baffling mystery to me. My best guess at this point is
> that it is due to some underlying change in Commons-Collections'
> ExtendedProperties class. But that seems kind of unlikely. Any
> insights? I'm about ready to give up and just find a workaround that
> makes gump happy, but if there is a bug coming down the line, that
> would not be helpful...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: gump failures, please help
Posted by Nathan Bubna <nb...@gmail.com>.
Thanks, Stefan. I actually believe i figured out the problem not long
after that email. It turns out to be a bad fix for COLLECTIONS-271
that causes ExtendedProperties to lose track of keys when combining
them via combine(ExtendedProperties). I'm taking the issue to them
now. Thanks for the gump tips, though, they may come in handy in the
future. :)
On Mon, Sep 8, 2008 at 2:49 AM, Stefan Bodewig <bo...@apache.org> wrote:
> [I kept both Velocity lists in CC, even though I'm not subscribed to
> either, we'll see how moderator approval turn out 8-)9
>
> On Fri, 5 Sep 2008, Nathan Bubna <nb...@gmail.com> wrote:
>
>> ok. after weeks of wrestling with gump to find out what the failures
>> are about, this last build gave some decent info.
>
> I'm sorry to hear that you've been wrestling with it and I'll be glad
> to offer any help I can.
>
> There are two main areas where Gump builds and your vanilla builds
> differ. One is the version of libraries you use and the other is the
> classloader setup (or lack thereof) in Ant based builds.
>
> Many times the problems come from the second part, so let me recap
> things even if you may already know them.
>
> At the top of Gump's build log you see the content of the CLASSPATh
> environment variable. Nothing else is on the CLASSPATH and nothing
> else (or less) will be on any classloader during the Ant build, at
> least for Ant tasks that honor build.sysclasspath.
>
> Could it be that you tests try to load configuration files via a
> classloader and fail in Gump because you set up the classpath within
> your build file but Gump ignores it? Watch out for <classpath>
> elements in your build file and make sure that everything that is
> required actually is listed in Gump's CLASSPATH.
>
> You can add new entries via <work> elements in the Gump descriptor.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: gump failures, please help
Posted by Nathan Bubna <nb...@gmail.com>.
Thanks, Stefan. I actually believe i figured out the problem not long
after that email. It turns out to be a bad fix for COLLECTIONS-271
that causes ExtendedProperties to lose track of keys when combining
them via combine(ExtendedProperties). I'm taking the issue to them
now. Thanks for the gump tips, though, they may come in handy in the
future. :)
On Mon, Sep 8, 2008 at 2:49 AM, Stefan Bodewig <bo...@apache.org> wrote:
> [I kept both Velocity lists in CC, even though I'm not subscribed to
> either, we'll see how moderator approval turn out 8-)9
>
> On Fri, 5 Sep 2008, Nathan Bubna <nb...@gmail.com> wrote:
>
>> ok. after weeks of wrestling with gump to find out what the failures
>> are about, this last build gave some decent info.
>
> I'm sorry to hear that you've been wrestling with it and I'll be glad
> to offer any help I can.
>
> There are two main areas where Gump builds and your vanilla builds
> differ. One is the version of libraries you use and the other is the
> classloader setup (or lack thereof) in Ant based builds.
>
> Many times the problems come from the second part, so let me recap
> things even if you may already know them.
>
> At the top of Gump's build log you see the content of the CLASSPATh
> environment variable. Nothing else is on the CLASSPATH and nothing
> else (or less) will be on any classloader during the Ant build, at
> least for Ant tasks that honor build.sysclasspath.
>
> Could it be that you tests try to load configuration files via a
> classloader and fail in Gump because you set up the classpath within
> your build file but Gump ignores it? Watch out for <classpath>
> elements in your build file and make sure that everything that is
> required actually is listed in Gump's CLASSPATH.
>
> You can add new entries via <work> elements in the Gump descriptor.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: gump failures, please help
Posted by Stefan Bodewig <bo...@apache.org>.
[I kept both Velocity lists in CC, even though I'm not subscribed to
either, we'll see how moderator approval turn out 8-)9
On Fri, 5 Sep 2008, Nathan Bubna <nb...@gmail.com> wrote:
> ok. after weeks of wrestling with gump to find out what the failures
> are about, this last build gave some decent info.
I'm sorry to hear that you've been wrestling with it and I'll be glad
to offer any help I can.
There are two main areas where Gump builds and your vanilla builds
differ. One is the version of libraries you use and the other is the
classloader setup (or lack thereof) in Ant based builds.
Many times the problems come from the second part, so let me recap
things even if you may already know them.
At the top of Gump's build log you see the content of the CLASSPATh
environment variable. Nothing else is on the CLASSPATH and nothing
else (or less) will be on any classloader during the Ant build, at
least for Ant tasks that honor build.sysclasspath.
Could it be that you tests try to load configuration files via a
classloader and fail in Gump because you set up the classpath within
your build file but Gump ignores it? Watch out for <classpath>
elements in your build file and make sure that everything that is
required actually is listed in Gump's CLASSPATH.
You can add new entries via <work> elements in the Gump descriptor.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: gump failures, please help
Posted by Stefan Bodewig <bo...@apache.org>.
[I kept both Velocity lists in CC, even though I'm not subscribed to
either, we'll see how moderator approval turn out 8-)9
On Fri, 5 Sep 2008, Nathan Bubna <nb...@gmail.com> wrote:
> ok. after weeks of wrestling with gump to find out what the failures
> are about, this last build gave some decent info.
I'm sorry to hear that you've been wrestling with it and I'll be glad
to offer any help I can.
There are two main areas where Gump builds and your vanilla builds
differ. One is the version of libraries you use and the other is the
classloader setup (or lack thereof) in Ant based builds.
Many times the problems come from the second part, so let me recap
things even if you may already know them.
At the top of Gump's build log you see the content of the CLASSPATh
environment variable. Nothing else is on the CLASSPATH and nothing
else (or less) will be on any classloader during the Ant build, at
least for Ant tasks that honor build.sysclasspath.
Could it be that you tests try to load configuration files via a
classloader and fail in Gump because you set up the classpath within
your build file but Gump ignores it? Watch out for <classpath>
elements in your build file and make sure that everything that is
required actually is listed in Gump's CLASSPATH.
You can add new entries via <work> elements in the Gump descriptor.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org