You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Max Rydahl Andersen <ma...@jboss.com> on 2005/06/05 20:31:28 UTC
classloading
hi guys,
Any particular reason why velocity only do Class.forName() where
it should first look in thread context classloader and THEN do
Class.forName() ?
(it gives some issues when running in environments with changing
classloaders, like
J2EE and Eclipse)
/max
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Stephen Morris <c-...@mci.com>.
As it turns out, method ResourceLoaderFactory.getLoader was already
modified to use the thread context classloader. Using a snapshot from
yesterday (with no modification), the problem goes away!
Thanks to all who participated in this discussion and fix... very
enlightening.
Is there a tutorial or article that covers this topic (class-loading in
the app-server environment)?
Thanks,
Steve
Stephen Morris wrote:
> I'm having a similar problem with Velocity (1.4) being able to
> instantiate a custom resource loader [see stack trace below].
>
> Would the fix to class
> ClasspathResourceLoader
> fix this problem also if applied to class:
>
> org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader
> ?
>
> Thanks,
> Steve
>
>
>
> Error is: java.lang.ClassNotFoundException:
> blah.blah.blah.MyCustomResourceLoader
> at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:141)
> at
> org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader(ResourceLoaderFactory.java:79)
>
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:185)
>
> at
> org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:502)
>
> at
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:268)
>
> at
> org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:441)
>
> at
> org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:148)
>
>
> Shinobu Kawai wrote:
>
>> Hi max,
>>
>>
>>
>>> Any particular reason why velocity only do Class.forName() where
>>> it should first look in thread context classloader and THEN do
>>> Class.forName() ?
>>>
>>> (it gives some issues when running in environments with changing
>>> classloaders, like
>>> J2EE and Eclipse)
>>>
>>
>>
>> Are we talking about the ClasspathResourceLoader? Then it's fixed in
>> the latest repository.
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>> For the latest in the repository:
>> http://cvs.apache.org/snapshots/velocity/
>>
>> Best regards,
>> -- Shinobu
>>
>> --
>> Shinobu Kawai <sh...@gmail.com>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Steve,
> I'm having a similar problem with Velocity (1.4) being able to
> instantiate a custom resource loader [see stack trace below].
>
> Would the fix to class
> ClasspathResourceLoader
> fix this problem also if applied to class:
>
> org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader
> ?
It would be great if you could try it and report it back to the list.
And maybe submit a patch. :)
Best regards,
-- Shinobu
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Stephen Morris <c-...@mci.com>.
I'm having a similar problem with Velocity (1.4) being able to
instantiate a custom resource loader [see stack trace below].
Would the fix to class
ClasspathResourceLoader
fix this problem also if applied to class:
org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader
?
Thanks,
Steve
Error is: java.lang.ClassNotFoundException:
blah.blah.blah.MyCustomResourceLoader
at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
org.apache.velocity.runtime.resource.loader.ResourceLoaderFactory.getLoader(ResourceLoaderFactory.java:79)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.initialize(ResourceManagerImpl.java:185)
at
org.apache.velocity.runtime.RuntimeInstance.initializeResourceManager(RuntimeInstance.java:502)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:268)
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.java:441)
at
org.apache.velocity.app.VelocityEngine.init(VelocityEngine.java:148)
Shinobu Kawai wrote:
>Hi max,
>
>
>
>>Any particular reason why velocity only do Class.forName() where
>>it should first look in thread context classloader and THEN do
>>Class.forName() ?
>>
>>(it gives some issues when running in environments with changing
>>classloaders, like
>>J2EE and Eclipse)
>>
>>
>
>Are we talking about the ClasspathResourceLoader? Then it's fixed in
>the latest repository.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>For the latest in the repository:
> http://cvs.apache.org/snapshots/velocity/
>
>Best regards,
>-- Shinobu
>
>--
>Shinobu Kawai <sh...@gmail.com>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Will Glass-Husain <wg...@forio.com>.
I'd support changing Class.forname to the thread context classloader.
We did a bunch of changes (in 1.5 dev) on this topic but not all.
Two tricky points to consider
* "ant test" has to pass. There's some cases in which ant does strange
things (shows up in the texen tests)
* If the Velocity jar is in the app server lib file, but the classes that
are being retrieved are in the web-app lib directory, this still needs to
work.
My suggestion is to replace any calls to Class.forName() with
ClassUtils.getNewInstance(). This has some fall back code that is required.
Best,
WILL
----- Original Message -----
From: "Nathan Bubna" <nb...@gmail.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Tuesday, June 07, 2005 9:15 AM
Subject: Re: classloading
good thought. and i'm fairly sure the answer is no, there's not
really much argument for the current state of things. one of the
original developers might have one, but as things have developed over
the years, the consensus has been that these are largely annoyances.
it's just that they apparently have never been annoying enough to
motivate anyone to step up to fix them (yet).
my understanding is that the Class.forName() stuff originated back
when that was the typical practice. the context classloader is
accepted as the right way for almost all situations now, including
velocity, i'm sure. and i don't think it'll cause any backwards
compatibility problems.
as for the overly verbose and dramatic logs, i think there is already
a bug or two filed on those, but i'm not aware of any patches. i
think if you provided a simple and backwards compatible patch to tame
those, Will would probably accept it (i hope). though i should make
one warning: talk of putting various messages in "categories" could
trigger another round of the commons-logging debate. my advice is to
keep the patch to anti-annoyance, and save any major logging
refactoring for later. bundling the two might kill both. :)
On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
> On Tue, 07 Jun 2005 17:13:01 +0200, Nathan Bubna <nb...@gmail.com> wrote:
>
> > patches would help :)
>
> yes - but before doing so just wanted to know if there were any argument
> for
> how it is done now ,)
>
> -max
>
> >
> > On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
> >> On Mon, 06 Jun 2005 20:17:38 +0200, Shinobu Kawai
> >> <sh...@gmail.com> wrote:
> >>
> >> > Hi max,
> >> >
> >> >> Any particular reason why velocity only do Class.forName() where
> >> >> it should first look in thread context classloader and THEN do
> >> >> Class.forName() ?
> >> >>
> >> >> (it gives some issues when running in environments with changing
> >> >> classloaders, like
> >> >> J2EE and Eclipse)
> >> >
> >> > Are we talking about the ClasspathResourceLoader? Then it's fixed in
> >> > the latest repository.
> >> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
> >> > For the latest in the repository:
> >> > http://cvs.apache.org/snapshots/velocity/
> >>
> >> I'm talking about
> >>
> >> FieldMethodizer
> >> RuntimeInstance
> >> LogManager
> >> ResourceManagerImpl
> >> ResourceLoaderFactory
> >> Generator
> >>
> >> While on the subject of things that "messes" up J2EE/Eclipse
> >> environments.
> >>
> >> Why is so much stuff logged as WARN/ERROR in Velocity ?
> >>
> >> Like:
> >> "ERROR: ResourceManager : unable to find resource
> >> 'VM_global_library.vm'
> >> in any resource loader."
> >>
> >> That should at least only be a WARN and it should be in a
> >> ResourceManager
> >> category so you could disable it.
> >>
> >> And:
> >> "Warning! The iterative is an Iterator in the #foreach() loop at [0,0]
> >> in
> >> template pojo/javaclass.vm. Because it's not resetable, if used in more
> >> than once, this may lead to unexpected results."
> >>
> >> Again, I undestand why this is there - but it should only be done on
> >> objects that is directly in the context (if at all). Printing out this
> >> warning
> >> for every iterator is simply not very usefull... e.g. printing this
> >> warning for a methodcall that does someList.iterator() is just noise.
> >>
> >> I removed this last one by providing my own UberSpectImpl, but it
> >> should
> >> not be necessary IMO.
> >>
> >> /max
> >>
> >>
> >>
> >> >
> >> > Best regards,
> >> > -- Shinobu
> >> >
> >> > --
> >> > Shinobu Kawai <sh...@gmail.com>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail:
> >> > velocity-user-help@jakarta.apache.org
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Nathan Bubna <nb...@gmail.com>.
good thought. and i'm fairly sure the answer is no, there's not
really much argument for the current state of things. one of the
original developers might have one, but as things have developed over
the years, the consensus has been that these are largely annoyances.
it's just that they apparently have never been annoying enough to
motivate anyone to step up to fix them (yet).
my understanding is that the Class.forName() stuff originated back
when that was the typical practice. the context classloader is
accepted as the right way for almost all situations now, including
velocity, i'm sure. and i don't think it'll cause any backwards
compatibility problems.
as for the overly verbose and dramatic logs, i think there is already
a bug or two filed on those, but i'm not aware of any patches. i
think if you provided a simple and backwards compatible patch to tame
those, Will would probably accept it (i hope). though i should make
one warning: talk of putting various messages in "categories" could
trigger another round of the commons-logging debate. my advice is to
keep the patch to anti-annoyance, and save any major logging
refactoring for later. bundling the two might kill both. :)
On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
> On Tue, 07 Jun 2005 17:13:01 +0200, Nathan Bubna <nb...@gmail.com> wrote:
>
> > patches would help :)
>
> yes - but before doing so just wanted to know if there were any argument
> for
> how it is done now ,)
>
> -max
>
> >
> > On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
> >> On Mon, 06 Jun 2005 20:17:38 +0200, Shinobu Kawai
> >> <sh...@gmail.com> wrote:
> >>
> >> > Hi max,
> >> >
> >> >> Any particular reason why velocity only do Class.forName() where
> >> >> it should first look in thread context classloader and THEN do
> >> >> Class.forName() ?
> >> >>
> >> >> (it gives some issues when running in environments with changing
> >> >> classloaders, like
> >> >> J2EE and Eclipse)
> >> >
> >> > Are we talking about the ClasspathResourceLoader? Then it's fixed in
> >> > the latest repository.
> >> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
> >> > For the latest in the repository:
> >> > http://cvs.apache.org/snapshots/velocity/
> >>
> >> I'm talking about
> >>
> >> FieldMethodizer
> >> RuntimeInstance
> >> LogManager
> >> ResourceManagerImpl
> >> ResourceLoaderFactory
> >> Generator
> >>
> >> While on the subject of things that "messes" up J2EE/Eclipse
> >> environments.
> >>
> >> Why is so much stuff logged as WARN/ERROR in Velocity ?
> >>
> >> Like:
> >> "ERROR: ResourceManager : unable to find resource 'VM_global_library.vm'
> >> in any resource loader."
> >>
> >> That should at least only be a WARN and it should be in a
> >> ResourceManager
> >> category so you could disable it.
> >>
> >> And:
> >> "Warning! The iterative is an Iterator in the #foreach() loop at [0,0]
> >> in
> >> template pojo/javaclass.vm. Because it's not resetable, if used in more
> >> than once, this may lead to unexpected results."
> >>
> >> Again, I undestand why this is there - but it should only be done on
> >> objects that is directly in the context (if at all). Printing out this
> >> warning
> >> for every iterator is simply not very usefull... e.g. printing this
> >> warning for a methodcall that does someList.iterator() is just noise.
> >>
> >> I removed this last one by providing my own UberSpectImpl, but it should
> >> not be necessary IMO.
> >>
> >> /max
> >>
> >>
> >>
> >> >
> >> > Best regards,
> >> > -- Shinobu
> >> >
> >> > --
> >> > Shinobu Kawai <sh...@gmail.com>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Max Rydahl Andersen <ma...@jboss.com>.
On Tue, 07 Jun 2005 17:13:01 +0200, Nathan Bubna <nb...@gmail.com> wrote:
> patches would help :)
yes - but before doing so just wanted to know if there were any argument
for
how it is done now ,)
-max
>
> On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
>> On Mon, 06 Jun 2005 20:17:38 +0200, Shinobu Kawai
>> <sh...@gmail.com> wrote:
>>
>> > Hi max,
>> >
>> >> Any particular reason why velocity only do Class.forName() where
>> >> it should first look in thread context classloader and THEN do
>> >> Class.forName() ?
>> >>
>> >> (it gives some issues when running in environments with changing
>> >> classloaders, like
>> >> J2EE and Eclipse)
>> >
>> > Are we talking about the ClasspathResourceLoader? Then it's fixed in
>> > the latest repository.
>> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
>> > For the latest in the repository:
>> > http://cvs.apache.org/snapshots/velocity/
>>
>> I'm talking about
>>
>> FieldMethodizer
>> RuntimeInstance
>> LogManager
>> ResourceManagerImpl
>> ResourceLoaderFactory
>> Generator
>>
>> While on the subject of things that "messes" up J2EE/Eclipse
>> environments.
>>
>> Why is so much stuff logged as WARN/ERROR in Velocity ?
>>
>> Like:
>> "ERROR: ResourceManager : unable to find resource 'VM_global_library.vm'
>> in any resource loader."
>>
>> That should at least only be a WARN and it should be in a
>> ResourceManager
>> category so you could disable it.
>>
>> And:
>> "Warning! The iterative is an Iterator in the #foreach() loop at [0,0]
>> in
>> template pojo/javaclass.vm. Because it's not resetable, if used in more
>> than once, this may lead to unexpected results."
>>
>> Again, I undestand why this is there - but it should only be done on
>> objects that is directly in the context (if at all). Printing out this
>> warning
>> for every iterator is simply not very usefull... e.g. printing this
>> warning for a methodcall that does someList.iterator() is just noise.
>>
>> I removed this last one by providing my own UberSpectImpl, but it should
>> not be necessary IMO.
>>
>> /max
>>
>>
>>
>> >
>> > Best regards,
>> > -- Shinobu
>> >
>> > --
>> > Shinobu Kawai <sh...@gmail.com>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Nathan Bubna <nb...@gmail.com>.
patches would help :)
On 6/7/05, Max Rydahl Andersen <ma...@jboss.com> wrote:
> On Mon, 06 Jun 2005 20:17:38 +0200, Shinobu Kawai
> <sh...@gmail.com> wrote:
>
> > Hi max,
> >
> >> Any particular reason why velocity only do Class.forName() where
> >> it should first look in thread context classloader and THEN do
> >> Class.forName() ?
> >>
> >> (it gives some issues when running in environments with changing
> >> classloaders, like
> >> J2EE and Eclipse)
> >
> > Are we talking about the ClasspathResourceLoader? Then it's fixed in
> > the latest repository.
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
> > For the latest in the repository:
> > http://cvs.apache.org/snapshots/velocity/
>
> I'm talking about
>
> FieldMethodizer
> RuntimeInstance
> LogManager
> ResourceManagerImpl
> ResourceLoaderFactory
> Generator
>
> While on the subject of things that "messes" up J2EE/Eclipse environments.
>
> Why is so much stuff logged as WARN/ERROR in Velocity ?
>
> Like:
> "ERROR: ResourceManager : unable to find resource 'VM_global_library.vm'
> in any resource loader."
>
> That should at least only be a WARN and it should be in a ResourceManager
> category so you could disable it.
>
> And:
> "Warning! The iterative is an Iterator in the #foreach() loop at [0,0] in
> template pojo/javaclass.vm. Because it's not resetable, if used in more
> than once, this may lead to unexpected results."
>
> Again, I undestand why this is there - but it should only be done on
> objects that is directly in the context (if at all). Printing out this
> warning
> for every iterator is simply not very usefull... e.g. printing this
> warning for a methodcall that does someList.iterator() is just noise.
>
> I removed this last one by providing my own UberSpectImpl, but it should
> not be necessary IMO.
>
> /max
>
>
>
> >
> > Best regards,
> > -- Shinobu
> >
> > --
> > Shinobu Kawai <sh...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi max,
> I'm talking about
>
> FieldMethodizer
> RuntimeInstance
> LogManager
> ResourceManagerImpl
> ResourceLoaderFactory
> Generator
I guess you can start by filing an issue. :)
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Velocity
> While on the subject of things that "messes" up J2EE/Eclipse environments.
>
> Why is so much stuff logged as WARN/ERROR in Velocity ?
>
> Like:
> "ERROR: ResourceManager : unable to find resource 'VM_global_library.vm'
> in any resource loader."
>
> That should at least only be a WARN and it should be in a ResourceManager
> category so you could disable it.
Solved in the repository.
http://issues.apache.org/bugzilla/show_bug.cgi?id=9938
> And:
> "Warning! The iterative is an Iterator in the #foreach() loop at [0,0] in
> template pojo/javaclass.vm. Because it's not resetable, if used in more
> than once, this may lead to unexpected results."
>
> Again, I undestand why this is there - but it should only be done on
> objects that is directly in the context (if at all). Printing out this
> warning
> for every iterator is simply not very usefull... e.g. printing this
> warning for a methodcall that does someList.iterator() is just noise.
>
> I removed this last one by providing my own UberSpectImpl, but it should
> not be necessary IMO.
And this one is here (not that it's fixed, though):
http://issues.apache.org/bugzilla/show_bug.cgi?id=7975
Best regards,
-- Shinobu
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Max Rydahl Andersen <ma...@jboss.com>.
On Mon, 06 Jun 2005 20:17:38 +0200, Shinobu Kawai
<sh...@gmail.com> wrote:
> Hi max,
>
>> Any particular reason why velocity only do Class.forName() where
>> it should first look in thread context classloader and THEN do
>> Class.forName() ?
>>
>> (it gives some issues when running in environments with changing
>> classloaders, like
>> J2EE and Eclipse)
>
> Are we talking about the ClasspathResourceLoader? Then it's fixed in
> the latest repository.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
> For the latest in the repository:
> http://cvs.apache.org/snapshots/velocity/
I'm talking about
FieldMethodizer
RuntimeInstance
LogManager
ResourceManagerImpl
ResourceLoaderFactory
Generator
While on the subject of things that "messes" up J2EE/Eclipse environments.
Why is so much stuff logged as WARN/ERROR in Velocity ?
Like:
"ERROR: ResourceManager : unable to find resource 'VM_global_library.vm'
in any resource loader."
That should at least only be a WARN and it should be in a ResourceManager
category so you could disable it.
And:
"Warning! The iterative is an Iterator in the #foreach() loop at [0,0] in
template pojo/javaclass.vm. Because it's not resetable, if used in more
than once, this may lead to unexpected results."
Again, I undestand why this is there - but it should only be done on
objects that is directly in the context (if at all). Printing out this
warning
for every iterator is simply not very usefull... e.g. printing this
warning for a methodcall that does someList.iterator() is just noise.
I removed this last one by providing my own UberSpectImpl, but it should
not be necessary IMO.
/max
>
> Best regards,
> -- Shinobu
>
> --
> Shinobu Kawai <sh...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: classloading
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi max,
> Any particular reason why velocity only do Class.forName() where
> it should first look in thread context classloader and THEN do
> Class.forName() ?
>
> (it gives some issues when running in environments with changing
> classloaders, like
> J2EE and Eclipse)
Are we talking about the ClasspathResourceLoader? Then it's fixed in
the latest repository.
http://issues.apache.org/bugzilla/show_bug.cgi?id=22419
For the latest in the repository:
http://cvs.apache.org/snapshots/velocity/
Best regards,
-- Shinobu
--
Shinobu Kawai <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org