You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by robert burrell donkin <ro...@mac.com> on 2001/09/23 00:21:26 UTC
LogKit + texen
i've just upgraded to the current cvs version of velocity
i'm now getting a NoSuchMethodError in
org.apache.velocity.runtime.log.AvalonLogSystem.init(AvalonLogSystem.java:
154) when i generate using texen now. i'd really like this generation to
work with the upcoming release since it's being used to refactor
jakarta-ecs.
i wondered if anybody has any tips (before i checkout avalon and start
looking at how it works or rather why it doesn't)...
- robert
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
On Saturday, September 22, 2001, at 11:33 PM, Geir Magnusson Jr. wrote:
> On 9/22/01 6:21 PM, "robert burrell donkin" <ro...@mac.com> wrote:
>
>> i've just upgraded to the current cvs version of velocity
>>
>> i'm now getting a NoSuchMethodError in
>> org.apache.velocity.runtime.log.AvalonLogSystem.init(AvalonLogSystem.java:
>> 154) when i generate using texen now. i'd really like this generation to
>> work with the upcoming release since it's being used to refactor
>> jakarta-ecs.
>>
>> i wondered if anybody has any tips (before i checkout avalon and start
>> looking at how it works or rather why it doesn't)...
>
> We have two texen tests in the testbed, and it works.
>
> What exactly are you doing?
i'm trying to commit a runnable generation system so that other people can
modify the generation scripts.
i'm trying to run with as much standard code as possible rather than using
the custom versions i usually run. everything was cool last time i updated
velocity but i don't do that very often.
> The init() method was added with the change to separate runtime instances.
> ..
hmmm,..
i'll try some clean complies and run those velocity tests on my machine.
(maybe it's caused by some change in texen which breaks the extensions i
use.)
- robert
Re: LogKit + texen
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/22/01 6:21 PM, "robert burrell donkin" <ro...@mac.com> wrote:
> i've just upgraded to the current cvs version of velocity
>
> i'm now getting a NoSuchMethodError in
> org.apache.velocity.runtime.log.AvalonLogSystem.init(AvalonLogSystem.java:
> 154) when i generate using texen now. i'd really like this generation to
> work with the upcoming release since it's being used to refactor
> jakarta-ecs.
>
> i wondered if anybody has any tips (before i checkout avalon and start
> looking at how it works or rather why it doesn't)...
We have two texen tests in the testbed, and it works.
What exactly are you doing?
The init() method was added with the change to separate runtime instances...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
Re: LogKit + texen
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/23/01 2:19 PM, "robert burrell donkin" <ro...@mac.com> wrote:
>
> On Sunday, September 23, 2001, at 02:51 PM, Geir Magnusson Jr. wrote:
>
>> Yes - the 'blow away the /bin' directory is something that is automatic
>> for
>> me on any real change, as ant doesn't do dependencies.
>
> yeh - good advice i usually try to follow. i gave it a go but i'm not
> really familiar with the velocity build script and might have made a
> mistake :)
>
> - robert
Here's a quick How-To :
$ cd jakarta-velocity
$ cd bin
$ rm -r *
$ cd ../build
$ ant jar
$ ant test
:)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
On Sunday, September 23, 2001, at 02:51 PM, Geir Magnusson Jr. wrote:
> Yes - the 'blow away the /bin' directory is something that is automatic
> for
> me on any real change, as ant doesn't do dependencies.
yeh - good advice i usually try to follow. i gave it a go but i'm not
really familiar with the velocity build script and might have made a
mistake :)
- robert
Re: LogKit + texen
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/23/01 7:38 AM, "robert burrell donkin" <ro...@mac.com> wrote:
> panic over :)
>
> everything started to work again after i edited the
> org.apache.velocity.runtime.log.AvalonLogSystem to put in some debugging
> stuff. continued working after that debugging code was removed. weird. (i
> thought i'd tried to clean build but...?)
Yes - the 'blow away the /bin' directory is something that is automatic for
me on any real change, as ant doesn't do dependencies.
Glad all is well.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
panic over :)
everything started to work again after i edited the
org.apache.velocity.runtime.log.AvalonLogSystem to put in some debugging
stuff. continued working after that debugging code was removed. weird. (i
thought i'd tried to clean build but...?)
- robert
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
On Sunday, September 23, 2001, at 07:03 PM, Jon Stevens wrote:
> on 9/23/01 1:59 AM, "robert burrell donkin" <ro...@mac.com> wrote:
>
>> Error: org.jdom.JDOMException: Error in building: SAX2 driver class
>> org.apache.xerces.parsers.SAXParser not found
>
> I believe this happens because of Ant 1.4...
>
> Try replacing the $ANT_HOME/lib/crimson.jar with xerces.jar
yeh i think that'd work
unfortunately, i've had problems generating using digester with xerces in
the classpath.
- robert
Re: LogKit + texen
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/23/01 1:59 AM, "robert burrell donkin" <ro...@mac.com> wrote:
> Error: org.jdom.JDOMException: Error in building: SAX2 driver class
> org.apache.xerces.parsers.SAXParser not found
I believe this happens because of Ant 1.4...
Try replacing the $ANT_HOME/lib/crimson.jar with xerces.jar
-jon
Test running fails?
Posted by Attila Szegedi <sz...@freemail.hu>.
I'm trying to run Velocity tests from the latest CVS sources, but it fails.
Can anyone quickly determine what does this fragment of output from issuing
"ant test" mean:
test-template:
[echo] Running Template tests...
[java] Failed to invoke suite():java.lang.NoSuchMethodError
BUILD FAILED
P:\Projects\jakarta\jakarta-velocity\build\testcases.xml:78: Java
returned: -1
Thanks,
Attila.
Re: Introspector, next turn
Posted by John McNally <jm...@collab.net>.
As far as property setters go, I see no reason not to have just the one
method, but doesn't velocity just use the same method invocation
solution for setters as it does any other method?
john mcnally
Attila Szegedi wrote:
>
> An issue cropped up:
>
> - Right now, ASTReference supports setting of a property, and will look up
> the setter method based on the property name AND the class of the right-hand
> side value. So, in current Velocity design a single property can have
> multiple property writers (i.e. both setFoo(Foo f) and setFoo(Bar b)). If we
> switch to JavaBeans introspection, we will always have a SINGLE property
> write method per property. Is this an issue of concern, or is this just an
> artifact of the fact that ASTReference uses Introspector.getMethod(), and we
> can happily switch over to using the single property write method returned
> from JavaBeans introspection? Fortunately, this is not issue for property
> read methods, as they have no arguments, so only one can exist for any given
> property name. I needn't say I favor the use of single property setter, the
> one returned from JavaBeans introspection.
>
> - BTW, is it any good having a template engine being able to call setXxx
> methods, thus potentially altering underlying data (or business) objects?
>
> Attila.
Re: Introspector, next turn
Posted by Jason van Zyl <jv...@apache.org>.
On 9/26/01 5:40 PM, "Roy T. Fielding" <fi...@ebuilt.com> wrote:
>> My point was that alteration of the model from within the template to me is
>> a violation of MVC but is deemed all right by Jon because it's a 'template
>> engineer' doing this. That's the part I don't buy. Hand those templates
>> you've worked on to a designer and I think you would be pretty much hosed.
>> Some just can't understand and the talented one's don't really feel it's
>> their job to have to deal with any logical constructs.
>
> That would make it pretty difficult to do what I did with Anakia on the
> site transformations. We walk the tree and transform only those elements
> and attributes that need to be transformed, allowing the remainder to
> pass through. If the context is read only, then we would have to copy
> the entire tree in memory first. That would suck.
Velocity used in the context of a tool like Anakia to me is a different
sitution. I was talking strictly in the sense of a webapp where the people
who are dealing with the view have a vague concept of programming at best.
In tools like Torque (and Anakia) a great deal of logic is performed in the
templates and I really like that (I put most of it there), but it is
understood that these templates are a convenient way to alter some logic
without having to recompile. If they are slightly hackish it probably
doesn't matter a great deal. But templates with the same degree complexity
thrown at a designer would probably make them cringe and cause them to throw
sharp objects at programmers passing by.
> ....Roy
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: Introspector, next turn
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> My point was that alteration of the model from within the template to me is
> a violation of MVC but is deemed all right by Jon because it's a 'template
> engineer' doing this. That's the part I don't buy. Hand those templates
> you've worked on to a designer and I think you would be pretty much hosed.
> Some just can't understand and the talented one's don't really feel it's
> their job to have to deal with any logical constructs.
That would make it pretty difficult to do what I did with Anakia on the
site transformations. We walk the tree and transform only those elements
and attributes that need to be transformed, allowing the remainder to
pass through. If the context is read only, then we would have to copy
the entire tree in memory first. That would suck.
....Roy
Re: Introspector, next turn
Posted by Jason van Zyl <jv...@apache.org>.
On 9/26/01 2:32 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> I believe that a designer shouldn't modify anything objects used in an
>> application, and again it's my opinion but I don't buy the template engineer
>> designation.
>
> I doubt all the template engineers at CollabNet would like that much.
What I meant is that most template engineers have Java experience and are
gaining more all the time. That a template engineer is really a java
programmer. It is basically programmers working at the template level and as
such constructs which I would consider part of the model make there way into
the view in being part of the template. It was in no way meant to deride the
designation of template engineer, my apologies if that's what came across.
My point was that alteration of the model from within the template to me is
a violation of MVC but is deemed all right by Jon because it's a 'template
engineer' doing this. That's the part I don't buy. Hand those templates
you've worked on to a designer and I think you would be pretty much hosed.
Some just can't understand and the talented one's don't really feel it's
their job to have to deal with any logical constructs.
I typically work with designers who have zero programming experience and as
such the templates have as little to do with programming as possible. I have
found in my personal experience that designers are not incapable of learning
things like #set, #if/#else/#end but they don't want to and don't care.
They just want to design. I basically have none of those constructs but I
admittedly have not been able to get rid of #foreach.
If you're going to put model/logical constructs in your template that's
fine. My gripe is the invention of the template engineer designation which
somehow makes it all right to still call that part of the view. If you
cannot hand those templates over to a designer and have them understand it
than I think you've violated MVC and this usually entails logical constructs
which in some way or another change the model.
Usually templates I make now, that are handed off to designers, can be
understood with a cursory glance at the Velocity docs. Some of my earlier
templates were considered by the people I worked with to be difficult to
understand and the designers felt uncomfortable changing much because they
weren't sure what was what. Again these designers are not dim, but they are
completely disinterested in things like
#set ($customer = $tool.getCustomer($id))
I remember talking to a guy at the servlet expert group @ java one and he
said he thought velocity sucked because it would totally confuse designers
and it confused the designers he worked with. I think the confusion can be
limited but any form of logical construct in the template can be confusing.
You are fortunate at collab that you've got many bright minds and are keen
to tinker with the templates. But the people I work with could care less and
complain if more than a #foreach or $variable reference have to be dealt
with.
Again, I was in no way making any sort of derogatory remark about template
designers I just asked that they been seen as what they are: people with
some java experience even if it is slight. People who are comfortable making
changes to the model from within a template. But I would venture to say that
most template engineers have more than a little java experience.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: Introspector, next turn
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> I believe that a designer shouldn't modify anything objects used in an
> application, and again it's my opinion but I don't buy the template engineer
> designation.
I doubt all the template engineers at CollabNet would like that much.
Re: Introspector, next turn
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/26/01 10:26 AM, "Jason van Zyl" <jv...@apache.org> wrote:
> I agree more with Attila here. My particular opinion but I think #set is a
> bad thing to put in a template for a webapp. I would even go so far as to
> say that objects placed in the context for use in a webapp should be read
> only.
I wasn't talking about #set.
Here is a somewhat lame example:
$looper.setCounter(0)
#foreach ($foo in $bar)
$looper.CounterIncrement
#end
Yes, I know that we have $velocityCount, it was my idea to add it. :-)
But, what if the Counter did something like return only even numbers or
something.
> I believe that a designer shouldn't modify anything objects used in an
> application, and again it's my opinion but I don't buy the template engineer
> designation.
I believe that is a Utopian view.
:-)
-jon
Re: Introspector, next turn
Posted by Jason van Zyl <jv...@apache.org>.
On 9/26/01 11:55 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 9/26/01 6:34 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
>
>> - BTW, is it any good having a template engine being able to call setXxx
>> methods, thus potentially altering underlying data (or business) objects?
>>
>> Attila.
>
> Yes. The reason why is that whatever you put into the Context, you have
> control over. Therefore, the setXxx methods that you make available are
> methods that you intended people to be able to use.
I agree more with Attila here. My particular opinion but I think #set is a
bad thing to put in a template for a webapp. I would even go so far as to
say that objects placed in the context for use in a webapp should be read
only.
I believe that a designer shouldn't modify anything objects used in an
application, and again it's my opinion but I don't buy the template engineer
designation.
> -jon
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: Introspector, next turn
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/26/01 6:34 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> - BTW, is it any good having a template engine being able to call setXxx
> methods, thus potentially altering underlying data (or business) objects?
>
> Attila.
Yes. The reason why is that whatever you put into the Context, you have
control over. Therefore, the setXxx methods that you make available are
methods that you intended people to be able to use.
-jon
Re: Introspector, next turn
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/26/01 9:34 AM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> An issue cropped up:
>
> - Right now, ASTReference supports setting of a property, and will look up
> the setter method based on the property name AND the class of the right-hand
> side value. So, in current Velocity design a single property can have
> multiple property writers (i.e. both setFoo(Foo f) and setFoo(Bar b)). If we
> switch to JavaBeans introspection, we will always have a SINGLE property
> write method per property. Is this an issue of concern, or is this just an
> artifact of the fact that ASTReference uses Introspector.getMethod(), and we
> can happily switch over to using the single property write method returned
> from JavaBeans introspection?
This is an issue of concern. Making all available is a really nice thing,
in my opinion. What problem are we trying to solve here, anyway?
> Fortunately, this is not issue for property
> read methods, as they have no arguments, so only one can exist for any given
> property name. I needn't say I favor the use of single property setter, the
> one returned from JavaBeans introspection.
>
> - BTW, is it any good having a template engine being able to call setXxx
> methods, thus potentially altering underlying data (or business) objects?
Yes - again, the idea that we offer such a transparent 'binding' to Java
objects is a great thing, in my opinion. It greatly extends the usefulness
of the API's offered to the template author.
For example, you can imagine all sorts of uses for this in a purely visual
context, such as
$rowcolorlaternator.setColors( ['red', 'blue', 'green'] )
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
Re: Introspector, next turn
Posted by Attila Szegedi <sz...@freemail.hu>.
An issue cropped up:
- Right now, ASTReference supports setting of a property, and will look up
the setter method based on the property name AND the class of the right-hand
side value. So, in current Velocity design a single property can have
multiple property writers (i.e. both setFoo(Foo f) and setFoo(Bar b)). If we
switch to JavaBeans introspection, we will always have a SINGLE property
write method per property. Is this an issue of concern, or is this just an
artifact of the fact that ASTReference uses Introspector.getMethod(), and we
can happily switch over to using the single property write method returned
from JavaBeans introspection? Fortunately, this is not issue for property
read methods, as they have no arguments, so only one can exist for any given
property name. I needn't say I favor the use of single property setter, the
one returned from JavaBeans introspection.
- BTW, is it any good having a template engine being able to call setXxx
methods, thus potentially altering underlying data (or business) objects?
Attila.
Re: Introspector, next turn
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/25/01 5:07 PM, "Attila Szegedi" <sz...@freemail.hu> wrote:
> It seems to me that Introspector.implementsMethod is dead code. Maybe it
> could get removed in a tidy-up.
Yep.
>
> Just to let you know, I started working on incorporating bean info obtained
> through java.beans.Introspector into Velocity introspection machinery. I'll
> yell when I'm done.
Yep.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
Introspector, next turn
Posted by Attila Szegedi <sz...@freemail.hu>.
It seems to me that Introspector.implementsMethod is dead code. Maybe it
could get removed in a tidy-up.
Just to let you know, I started working on incorporating bean info obtained
through java.beans.Introspector into Velocity introspection machinery. I'll
yell when I'm done.
Attila.
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
On Sunday, September 23, 2001, at 04:40 PM, Jason van Zyl wrote:
> On 9/23/01 4:59 AM, "robert burrell donkin" <ro...@mac.com> wrote:
<snip>
>>> Let us know what's special about what you are doing.
>>
>> 1. i'm running those cool texen extensions that jason doesn't like :)
>
> What texen extensions? I guess I forgot because I'm not sure what you're
> talking about.
(thought that'd wake you up ;-)
i think you had a quick look at them a while back.
it's that texen subclass that allows dynamic extensibility (rather than
having to create a new subclass every time). i sort of agree with what you
said about the changes being complex and adding only a small amount of
functionality. i like them because i think they produce more readable
build scripts and generation templates. (i've also got a load of useful
templates that i'd have to convert.)
i had planned to resubmit them when the jakarta-velocity-texen sub-project
gets off the ground.
i could probably live with a sufficiently general digester-based subclass.
the idea is that you'd specify a ruleset class by name and that'd be
loaded into digester by the subclass and used to create the object model
passed into the generation template. that way, you don't to write a new
texen subclass, just write - or generate - an object model and a set of
rules to create that object model from the xml fed in.
- robert
Re: LogKit + texen
Posted by Jason van Zyl <jv...@apache.org>.
On 9/23/01 4:59 AM, "robert burrell donkin" <ro...@mac.com> wrote:
> On Saturday, September 22, 2001, at 11:44 PM, Geir Magnusson Jr. wrote:
>
>> Just to give you the warm fuzzies, I made sure my code tree was
>> up-to-date,
>> blew away the bin dir, did an 'ant jar', and then 'ant test', and all was
>> well.
>
> ant test falls down on anakia
>
> i'm getting a JDOM error
>
> Error: org.jdom.JDOMException: Error in building: SAX2 driver class
> org.apache.xerces.parsers.SAXParser not found
>
> i can't find a version on my JDOM but i guess that it's pretty old (it
> worked last time i used anakia).
>
>> Let us know what's special about what you are doing.
>
> 1. i'm running those cool texen extensions that jason doesn't like :)
What texen extensions? I guess I forgot because I'm not sure what you're
talking about.
> 2. i have to have the use latest commons stuff (like collections) in the
> classpath
> 3. i have to use JAXP
>
> - robert
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
Re: LogKit + texen
Posted by robert burrell donkin <ro...@mac.com>.
On Saturday, September 22, 2001, at 11:44 PM, Geir Magnusson Jr. wrote:
> Just to give you the warm fuzzies, I made sure my code tree was
> up-to-date,
> blew away the bin dir, did an 'ant jar', and then 'ant test', and all was
> well.
ant test falls down on anakia
i'm getting a JDOM error
Error: org.jdom.JDOMException: Error in building: SAX2 driver class
org.apache.xerces.parsers.SAXParser not found
i can't find a version on my JDOM but i guess that it's pretty old (it
worked last time i used anakia).
> Let us know what's special about what you are doing.
1. i'm running those cool texen extensions that jason doesn't like :)
2. i have to have the use latest commons stuff (like collections) in the
classpath
3. i have to use JAXP
- robert
Re: LogKit + texen
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/22/01 6:21 PM, "robert burrell donkin" <ro...@mac.com> wrote:
> i've just upgraded to the current cvs version of velocity
>
> i'm now getting a NoSuchMethodError in
> org.apache.velocity.runtime.log.AvalonLogSystem.init(AvalonLogSystem.java:
> 154) when i generate using texen now. i'd really like this generation to
> work with the upcoming release since it's being used to refactor
> jakarta-ecs.
>
> i wondered if anybody has any tips (before i checkout avalon and start
> looking at how it works or rather why it doesn't)...
>
> - robert
Just to give you the warm fuzzies, I made sure my code tree was up-to-date,
blew away the bin dir, did an 'ant jar', and then 'ant test', and all was
well.
Let us know what's special about what you are doing.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb