You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Gabriel Sidler <si...@teamup.ch> on 2002/05/02 22:45:37 UTC
Re: [Veltools] ToolboxManager (round 4 :-)
Nathan,
I finally got around to study your latest proposal regarding the tool
management. Overall I like the approach and think it is a good basis
to move on.
I'd like to make a few remarks/suggestions:
- Your proposed DTD for the toolbox configuration makes good sense
to me. The minor exception is that the 'scope' element seems to be
missing. Or, am I missing something?
- In our past discussion Dan argued for a destroy() method
as part of the ContextTool interface. This would be the place to do
clean-up work or release resources. Your current proposal doesn't
address this. What's your thinking on that.
- ServletToolInfo.java: Here you add scope support to tool info. I have
no problem with the implemenation of the class but think that the
name is not the most appropriate one. In my view the concept of 'scope'
is not limited to a servlet environment. In fact, no part of the class
implementation is dependent on the Servlet API. Assume that I want to implement
a toolbox manager for DVSL. In such an environment the scopes "request"
and "application" make perfect sense. I see two possible resolutions:
- Rename the class to ScopedToolInfo
- Merge ServletToolInfo and ContextToolInfo and name the class ContextToolInfo.
I actually don't see an advantage of having two classes instead of one.
Maybe I overlook something?
- ServletToolboxManager.getToolboxContext(): The instantiation of
session tools should be synchronized, otherwise it might happen that
the session-scoped tools are instantiated multiple times for the same
session.
- I am quite uncomfortable with the proposed init method of ContextTool.
public void init(Object initData);
This is virtually moving us back to C-times where we worked with pointers
and suffered from all kind of related problems. The interface is basically
specified through the documentation. Yes, this approach
keeps the interface between tools and the toolbox manager simple. But,
the price is a problematic, underspecified, error-prone interface. That's
too high a price. Especially since we are not talking about very many
different init-cases. Currently we have identified two cases:
- Tools that need access to the servlet environment
- Tools that need access to the Velocity context
I really think we should go the extra mile and handle these two cases
with two specific interfaces.
Nathan wrote:
> (Gabe, if you would really prefer to call this "ViewTool", I can live with
> it. But i still think ContextTool will be more meaningful to users.)
I really would prefer ViewTool. From talking to people, my experience
is that ViewTool is more intuitive than ContextTool.
Furthermore, there is nothing about these tools that is specific to
the context. Much more, they are specific to the view layer. If you
consider a situation where the same tool is used with multiple view
technologies, then 'context tool' seems quite inappropriate.
That's all I have. I am looking forward to your feedback on the
mentioned points.
Gabe
Nathan Bubna wrote:
> Ok. I've rewritten this stuff pretty heavily, so bear with me if this
> proposal gets a little long...
>
> First, i think it'd be good to have a generic ToolboxManager interface.
> This should allow for varying implementations (dvsl, vvs, etc.) So I figure
> we need a way to tell the manager what to manage, and a way to get the
> toolbox context.
>
> public interface ToolboxManager
> {
> void addTool(ToolInfo info);
>
> ToolboxContext getToolboxContext(Object initData);
> }
>
> I think that's probably all we really need. I don't want to put
> load(InputStream) here, in case we want to load some other way.
>
> Now, the ToolInfo class should provide enough information for the manager to
> appropriately manage the tools. I don't want to pass the tool directly,
> because I don't want to force programmers to hard-code info that's pertitent
> to the management of the tool, but not to the tool's actual functions. So,
> I figure the bare bones ToolInfo should be something like:
>
> public interface ToolInfo
> {
> String getKey();
>
> String getClassname();
>
> Object getInstance(Object initData);
> }
>
> You can get the key, the class of the tool, and an actual instance of the
> tool.
> At this point, you are probably wondering about this initData stuff. Well,
> I decided to take a tip from Turbine. Instead of having a new interface for
> every type of tool initialization people come up with, i figure we really
> only need one:
>
> public interface ContextTool
> {
> public void init(Object initData);
> }
>
> (Gabe, if you would really prefer to call this "ViewTool", I can live with
> it. But i still think ContextTool will be more meaningful to users.)
>
> since we're going to use ToolInfo objects to deal with info about the tool,
> we don't need to use interfaces as markers anymore. so, there really isn't
> any point to having umpteen different virtually identical initialization
> interfaces. we can just leave it up to the tool to deal with the initData
> as need be. this has worked well for Turbine's PullService, and i think it
> will work well here. We provide the hook for the initData to be passed to
> the toolbox manager on toolbox context requests, and implementations of the
> manager can then pass it on to the ToolInfo in order to get an initialized
> tool instance. those tools which implement ContextTool would then
> appropriately cast the initData and use it. The other obvious benefit of
> this is that we don't explicitly pass the ViewContext anymore (which is tied
> to the servlet environment).
>
> ---
> Ok, that's the fundamentals. Now to discuss the implementations I've
> attached to this email.
>
> One major need in the current toolbox system is the ability to specify raw
> data constants as tools (String, Number, Boolean). That's what the DataInfo
> class is for; it provides a fitting constructor to build the info and
> implements getInstance() efficiently.
>
> The ContextToolInfo class offers an efficient means to deal with arbitrary
> classes as tools, and in particular, it makes clean use of the ContextTool
> interface to initialize tools appropriately.
>
> ServletToolInfo extends ContextToolInfo to hold additional information about
> the tool's scope placement.
>
> I can also envision someone creating a Poolable interface that offers a
> destroy()/reset() method, and implementing a PoolableToolInfo class that
> pools instances of Poolable tools in order to more efficiently implement
> getInstance(). I'm not convinced that these belong in this project though.
> keep it simple...
>
> XMLToolboxManager is an implemenation of ToolboxManager that has no servlet
> environment ties and loads the toolbox from xml. I would hope that this is
> a large step towards abstracting tool management. Since we never really
> agreed on a common DTD for dvsl and vvs, i just made my own:
>
> <?xml version="1.0"?>
> <!ELEMENT toolbox (tool*,data*)>
> <!ELEMENT tool (key,class,#PCDATA)>
> <!ELEMENT data (key,value)>
> <!ATTLIST data type (string|number|boolean) "string">
> <!ELEMENT key (#CDATA)>
> <!ELEMENT class (#CDATA)>
> <!ELEMENT value (#CDATA)>
>
> feel free to criticize, improve, whatever as always. i don't really have
> muc experience with DTD/XML stuff, so it may be totally whacked. it would
> probably also be nice to have it defined as an XML Schema, but i didn't
> bother as i didn't put much thought in here to begin with. Anyway, that's
> the layout XMLToolboxManager currently reads. Note that i have implemented
> the raw data loading as well as the arbitrary class loading. the actual
> management implemented is, however, quite minimal. it may be useful in some
> instances, but for VVS, we really need...
>
> ServletToolboxManager. it extends XMLToolboxManager to appropriately read
> ServletToolInfo and efficiently implement the addTool and getToolboxContext
> methods for the VVS.
>
> I haven't done any serious testing of the code, but i did update my current
> app to use it and it worked like a charm. Of course, in that process, i
> also had to update all the existing struts and other tools to work with this
> system, so i will happily send patches for those if so desired.
>
> Now, you probably noticed that i didn't implement any of the tool logging
> stuff. This is because I finally got around to really thinking about it,
> and i decided i don't like the idea of adding our own logging stuff. There
> are plenty of well tested, designed, and used logging APIs out there
> already. If you have a custom tool that really needs logging, I think it
> would be best if you used one of those. As for the VVS tools that we have
> in this codebase, most need virtually no logging, and the ones that
> reasonably do need logging have access to the ServletContext and can just
> log to that. I really don't see good reason to starting getting all
> framework-ish and mess around with our own logging API.
>
> If, of course, you really really want to write your own logging stuff, It
> should be easy enough to write your own ToolInfo/ToolboxManager
> implementations to take care of that.
>
> So, in my code, i have removed:
> ViewToolLogger
> ServletViewToolLogger
> LogEnabledContextTool
> LogEnabledContextToolImpl
>
> as well as the old tool interfaces:
> ContextViewTool
> ServletViewTool
> ThreadSafeViewTool
>
> Well, i guess now's the time to begin the feedback/rejection process. :-) I
> hope you'll take a decent look at the code first. That should help prevent
> some misunderstandings. I can also provide you with my new
> velocity-tools-view.jar if you desire.
>
> Things are picking up at work again, so i won't have much time for this in
> the next few weeks, but i'll do what i can.
>
> Nathan Bubna
> nathan@esha.com
>
>
>
> ------------------------------------------------------------------------
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Nathan Bubna <na...@esha.com>.
Gabe said:
> Ok, I got your points. I do not agree with all your arguments but these
> point of disagreement are mostly related to possible future uses of the
> software in other environments. I think that the current proposal supports
> all the key features that we need to move on. Feedback from users and real
> applications will tell us in the future if all the design decisions were
> right.
>
> The one thing that I really would like to get fixed is the synchronization
> of the instantiation of the session tools (see my points below).
ok.
> I propose that you send me all the modifed files and I will
> then check them in. Please make sure that the JavaDoc is reflecting the
> latest design.
sure, the synchronization change should only take a second. bear with me on
the javadoc if i miss something.
so what is the call on ViewTool vs. ContextTool? no one else has offered an
opinion or vote so far, and you and I aren't in agreement. i guess if no
one breaks the tie, i'll go ahead and change my proposed code to use
'ViewTool' in deference to your committer status.
[snip]
> >>I can also envision someone creating a Poolable interface that offers a
> >>destroy()/reset() method, and implementing a PoolableToolInfo class that
> >>pools instances of Poolable tools in order to more efficiently implement
> >>getInstance(). I'm not convinced that these belong in this project
>
> I am not talking about the pooling of tools. There are two different
issues
> here. One issue is the need to release resources after the tool has been
used.
> A proposed solution was to have a destroy() method. Dan reported a need
for
> that (it was part of the original design but removed later). The other
issue
> is the pooling of tools for efficiency. We agree that this is not high
priority
> right now.
what is "need to release resources"? i was only ever taught as a java
programmer. i don't know what that means. :-) (i'm kidding of course...
well... sorta :-)
you say this is a problem "after the tool has been used", but if we no
longer hold a reference to the tool, the garbage collector should release
the resources. why hold on to the tool reference if not for pooling? that
sounds like a fairly unique case, and should probably just be implemented by
the designer. the only standard situation i'm familiar with that should
have this destroy() functionality is pooling, but maybe that's just my
ignorance. no matter, we'll get to this later.
[snip]
> >>Nathan wrote:
> >> > (Gabe, if you would really prefer to call this "ViewTool", I can
live
> >> with it. But i still think ContextTool will be more meaningful to
users.)
> >>I really would prefer ViewTool. From talking to people, my experience
> >>is that ViewTool is more intuitive than ContextTool.
> >>
> > your experience perhaps, but not mine. i've been lurking on the
velocity
> > lists for well over a year and never heard the term 'view tool' until
you
> > committed that change to the veltools project.
>
> So you can't live with it? :-)
>
> > >>Furthermore, there is nothing about these tools that is specific to
> >>the context.
> >>
> > ? so it doesn't mean anything to you that the whole purpose of these
tools
> > is to be placed in the velocity context?
>
> I claim that the purpose of these tools is not to be placed in the
> Velocity context but to provide some utility to the view layer,
> whatever this view layer is. :-)
heh. now we're really pushing the boundaries :-) this is, after all, a
velocity sub-project...
> I personally use some of my view tools in JSP and Velocity. I am
> sure many Struts users would want to do the same. The name context tool
> doesn't really have a meaning outside of Velocity. But, many view tools
> have very much a purpose outside the Velocity environment. So, we can
> use our own terminology or use something that has a meaning in other
> environments as well. Another term I occasionally read on the Struts
> list is "view helper"
>
>
> I think enough has been said. Let's get this code into the repository.
> I want to get the Struts stuff out to Struts users so that we can
> gather some real feedback.
I'll try and get the revised code out to you today, but it might be first
thing monday. I'll send patches for the existing tools as well since i've
already changed those too.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Veltools] Proposed patch for the DateTool
Posted by Claude Brisson <cl...@savoirweb.com>.
Hi all.
Here is a proposed patch for DateTool : a new toDate(format,object) method that allows the parsing of a date according to the
specified format.
The format is used only if the passed object is not of Date or Calendar type (hence expected to be a String) : this is homogeneic
with the existing toDate(obj) method.
Sincerely,
CloD
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Nathan Bubna <na...@esha.com>.
Sean said:
> In message <05...@zeus.esha.com>, Nathan Bubna
> <na...@esha.com> writes
> >> well how about both interfaces implementing a common base interface
that
> >> has all the methods bar init?
> >
> >heh. the "init" method is the only method at present.
>
> oh, okay - didn't take a close enough look. In that case two interfaces
> seems very reasonable, they're both doing different things. And a tool
> that wanted to be able to live in both scopes could implement both
> interfaces ...
I agree--two interfaces does seem very reasonable. I could probably even
live with three interfaces if Turbine took that road. However, i don't
think two or three interfaces will be enough. One of the goals we've had
here is to create generic velocity tool/data management. We want to create
a toolbox system that can be easily used to populate the context for a
variety of different environments using velocity. So far, yes, we have only
really worked on a toolbox for the servlet environment where we can easily
get by with just two or three interfaces (as Turbine could and perhaps
should). But when you look outward to using this stuff for dvsl or other
environments, having interface methods like
init(javax.servlet.ServletRequest) become cruft and the toolbox code we've
written is useless to them. In contrast, by keeping the tool interface and
toolbox manager as generic as possible, we allow them to be used with some
consistency across a variety of environments. I think the compile-time
ambiguity introduced is perfectly acceptable in light of the benefits.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by sean <se...@datamage.net>.
In message <05...@zeus.esha.com>, Nathan Bubna
<na...@esha.com> writes
>> well how about both interfaces implementing a common base interface that
>> has all the methods bar init?
>
>heh. the "init" method is the only method at present.
oh, okay - didn't take a close enough look. In that case two interfaces
seems very reasonable, they're both doing different things. And a tool
that wanted to be able to live in both scopes could implement both
interfaces ...
--
Sean Legassick
sean@datamage.net
Als Mensch kann mir nichts menschliches Fremd sein
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Nathan Bubna <na...@esha.com>.
Sean said:
> Nathan said:
> >well, it looks like we've only got two suggestions so far. one is to
create
> >a new virtually identical interface for each type of init data we can
come
> >up with, and the other is to use one interface that takes an Object.
> >
> >any lateral thinkers out there got a better way?
>
> well how about both interfaces implementing a common base interface that
> has all the methods bar init?
heh. the "init" method is the only method at present. the only other
method that i can ever imagine being added is a destroy/reset method, but
i'm presently still of the opinion that that would be long in a completely
separate interface.
my "virtually identical" complaint stems from the fact the all the
interfaces would be:
public interface MyFavoriteToolInterface
{
void init(MyFavoriteInitDataClass initData);
}
so, extending a common interface doesn't really help the matter.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by sean <se...@datamage.net>.
In message <02...@zeus.esha.com>, Nathan Bubna
<na...@esha.com> writes
>Sean said:
>well, it looks like we've only got two suggestions so far. one is to create
>a new virtually identical interface for each type of init data we can come
>up with, and the other is to use one interface that takes an Object.
>
>any lateral thinkers out there got a better way?
well how about both interfaces implementing a common base interface that
has all the methods bar init?
--
Sean Legassick
sean@datamage.net
Soy un hombre: nada humano me es extrano
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Nathan Bubna <na...@esha.com>.
Sean said:
> >>>- I am quite uncomfortable with the proposed init method of
> >>>ContextTool.
> >>>
> >>> public void init(Object initData);
> >>>
> >>> This is virtually moving us back to C-times where we worked with
pointers
> >>> and suffered from all kind of related problems. The interface is
basically
> >>> specified through the documentation. Yes, this approach
> >>> keeps the interface between tools and the toolbox manager simple.
But,
> >>> the price is a problematic, underspecified, error-prone interface.
> >>>
> >> That's too high a price.
> >>>
> >> Really? I'll be sure to pass that on to Turbine-land where this has
> >>worked
> >> great for their PullService for quite some time now. Someone should
warn
> >> them of their impending doom! :-) ok, maybe that's a little
dramatic...
> >
> >Well, I don't think this pull tool interface it their masterpiece of
software
> >engineering. It's a working compromise.
>
> As co-author of the Turbine PullService, I have to agree with Gabe here.
> I was never completely happy with this aspect of the API, and really
> only agreed to implement it because there was a precedent elsewhere in
> the Turbine code (can't remember where now).
heh, figures. thanks for the info.
> If you can find a better approach, use it! (And maybe suggest the
> improvement back over in Turbine-land).
well, it looks like we've only got two suggestions so far. one is to create
a new virtually identical interface for each type of init data we can come
up with, and the other is to use one interface that takes an Object.
any lateral thinkers out there got a better way? given the choice between
the two, i definitely prefer the single-interface. the fact still remains
that it has worked well for me in our turbine apps, and it is the simpler
solution. i can handle a little ambiguity if it will give me greater
flexibility. in Turbine i guess i can see more reason to go specific
interfaces (for session/User, request/RunData, etc.), because the
PullService is explicitly tied into Turbine and the servlet environment.
Since we are trying to keep the toolbox management accessible to DVSL and
other environments beyond servlets, I'm much less eager to start down the
path of adding a new tool interface everytime someone has a new class they
want to use to initialize their tools. I really can't see how we can
generalize the ToolboxManager without having a generic tool interface. i.e.
it doesn't make much sense to have a ToolboxManager interface with a
getToolboxContext(Object initData) if the tool interface doesn't have a
init(Object initData). we're certainly not going to add a new
getToolboxContext(SomeClass sc) method to ToolboxManager for each type of
initData, so we must either find an entirely different way to generalize
management tools, keep the tool interface matched to the ToolboxManager
interface as i proposed, or forget generalizing the tool management and go
back to developing wholly independent managers for each environment.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by sean <se...@datamage.net>.
In message <3C...@teamup.ch>, Gabriel Sidler
<si...@teamup.ch> writes
>>>- I am quite uncomfortable with the proposed init method of
>>>ContextTool.
>>>
>>> public void init(Object initData);
>>>
>>> This is virtually moving us back to C-times where we worked with pointers
>>> and suffered from all kind of related problems. The interface is basically
>>> specified through the documentation. Yes, this approach
>>> keeps the interface between tools and the toolbox manager simple. But,
>>> the price is a problematic, underspecified, error-prone interface.
>>>
>> That's too high a price.
>>>
>> Really? I'll be sure to pass that on to Turbine-land where this has
>>worked
>> great for their PullService for quite some time now. Someone should warn
>> them of their impending doom! :-) ok, maybe that's a little dramatic...
>
>Well, I don't think this pull tool interface it their masterpiece of software
>engineering. It's a working compromise.
As co-author of the Turbine PullService, I have to agree with Gabe here.
I was never completely happy with this aspect of the API, and really
only agreed to implement it because there was a precedent elsewhere in
the Turbine code (can't remember where now).
If you can find a better approach, use it! (And maybe suggest the
improvement back over in Turbine-land).
--
Sean Legassick
sean@datamage.net
ignorance is not bliss
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Gabriel Sidler <si...@teamup.ch>.
Ok, I got your points. I do not agree with all your arguments but these
point of disagreement are mostly related to possible future uses of the
software in other environments. I think that the current proposal supports
all the key features that we need to move on. Feedback from users and real
applications will tell us in the future if all the design decisions were
right.
The one thing that I really would like to get fixed is the synchronization
of the instantiation of the session tools (see my points below).
I propose that you send me all the modifed files and I will
then check them in. Please make sure that the JavaDoc is reflecting the
latest design.
I have added some replys to your comments below.
Gabe
Nathan Bubna wrote:
> Gabe said:
>
...
>>- In our past discussion Dan argued for a destroy() method
>>as part of the ContextTool interface. This would be the place to do
>>clean-up work or release resources. Your current proposal doesn't
>>address this. What's your thinking on that.
>>
>
> actually, i did address it, but here it is again:
>
> Nathan said:
>
>>I can also envision someone creating a Poolable interface that offers a
>>destroy()/reset() method, and implementing a PoolableToolInfo class that
>>pools instances of Poolable tools in order to more efficiently implement
>>getInstance(). I'm not convinced that these belong in this project
I am not talking about the pooling of tools. There are two different issues
here. One issue is the need to release resources after the tool has been used.
A proposed solution was to have a destroy() method. Dan reported a need for
that (it was part of the original design but removed later). The other issue
is the pooling of tools for efficiency. We agree that this is not high priority
right now.
...
>
>>- ServletToolboxManager.getToolboxContext(): The instantiation of
>> session tools should be synchronized, otherwise it might happen that
>> the session-scoped tools are instantiated multiple times for the same
>> session.
>>
>
> this too has been discussed at length. i think it's an incredibly paranoid
> thing to do. if done correctly, it wouldn't be too much of a performance
> hit, but IMO, if the current design is problematic for a tool designer, it
> is the fault of their tool design, not the fault of the toolbox manager.
> anyway, you seem stuck on the idea, and i can't stop you from doing it. so
> do what you will, i'm tired of arguing about it.
You are mixing two things: You are talking about the thread safety of
tools. I am talking about the thread-safety of the toolbox manager.
I don't understand why we need so much discussion about thread-safety.
This is not an esoteric, magical concept but rather a basic concept of
software engineering.
A piece of software that is used concurrently from multiple threads must
be thread-safe. Anything else is a bug. This is pretty black and white
in my view. I don't think this has anything to do with being paranoid.
I worked on a large collaborative web appliation for a call center
environment; kind of a chat tool for customer support. We've had our share
of threading problems. I can assure you that these problems are real and
do happen. There is not much that is worse to debug. It is really worth
to pay attention to this.
>
>
>>- I am quite uncomfortable with the proposed init method of ContextTool.
>>
>> public void init(Object initData);
>>
>> This is virtually moving us back to C-times where we worked with pointers
>> and suffered from all kind of related problems. The interface is basically
>> specified through the documentation. Yes, this approach
>> keeps the interface between tools and the toolbox manager simple. But,
>> the price is a problematic, underspecified, error-prone interface.
>>
> That's too high a price.
>>
>
> Really? I'll be sure to pass that on to Turbine-land where this has worked
> great for their PullService for quite some time now. Someone should warn
> them of their impending doom! :-) ok, maybe that's a little dramatic...
Well, I don't think this pull tool interface it their masterpiece of software
engineering. It's a working compromise.
> And where do you get this "problematic, underspecified, error-prone" stuff?
> I see no problems (remember, i've already implemented and tested this code
> and it worked great!).
In your design, the interface between toolbox manager and tools is partially
defined in the documentation. This makes it impossible for a compiler or
the toolbox manager to detect a mismatch of classes. I tought we left that
behind with C...
In any case, for the current environment the current proposal is a working
proposal. That's why I propose that we incorporate your current proposal
and move on.
...
>>Nathan wrote:
>> > (Gabe, if you would really prefer to call this "ViewTool", I can live
>> with it. But i still think ContextTool will be more meaningful to users.)
>>I really would prefer ViewTool. From talking to people, my experience
>>is that ViewTool is more intuitive than ContextTool.
>>
>
> your experience perhaps, but not mine. i've been lurking on the velocity
> lists for well over a year and never heard the term 'view tool' until you
> committed that change to the veltools project.
So you can't live with it? :-)
> >>Furthermore, there is nothing about these tools that is specific to
>>the context.
>>
>
> ? so it doesn't mean anything to you that the whole purpose of these tools
> is to be placed in the velocity context?
I claim that the purpose of these tools is not to be placed in the
Velocity context but to provide some utility to the view layer,
whatever this view layer is. :-)
I personally use some of my view tools in JSP and Velocity. I am
sure many Struts users would want to do the same. The name context tool
doesn't really have a meaning outside of Velocity. But, many view tools
have very much a purpose outside the Velocity environment. So, we can
use our own terminology or use something that has a meaning in other
environments as well. Another term I occasionally read on the Struts
list is "view helper"
I think enough has been said. Let's get this code into the repository.
I want to get the Struts stuff out to Struts users so that we can
gather some real feedback.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Nathan Bubna <na...@esha.com>.
Gabe said:
> Nathan,
> I finally got around to study your latest proposal regarding the tool
> management. Overall I like the approach and think it is a good basis
> to move on.
well, it's a start at least.
> I'd like to make a few remarks/suggestions:
>
> - Your proposed DTD for the toolbox configuration makes good sense
> to me. The minor exception is that the 'scope' element seems to be
> missing. Or, am I missing something?
<!ELEMENT tool (key,class,#PCDATA)>
a scope element would fall under the parsed character data here, right? i
could be wrong; i haven't worked with DTD's much.
The reason i went with the open ended #PCDATA was to open the floor for
other tool attributes. i don't expect scope to be relevant to all tool
types and therefore don't think it should not be a part of the general DTD.
i'd rather leave that to the specific application to determine.
> - In our past discussion Dan argued for a destroy() method
> as part of the ContextTool interface. This would be the place to do
> clean-up work or release resources. Your current proposal doesn't
> address this. What's your thinking on that.
actually, i did address it, but here it is again:
Nathan said:
> I can also envision someone creating a Poolable interface that offers a
> destroy()/reset() method, and implementing a PoolableToolInfo class that
> pools instances of Poolable tools in order to more efficiently implement
> getInstance(). I'm not convinced that these belong in this project
though.
> keep it simple...
> - ServletToolInfo.java: Here you add scope support to tool info. I have
> no problem with the implemenation of the class but think that the
> name is not the most appropriate one. In my view the concept of 'scope'
> is not limited to a servlet environment.
we've discussed this already rather extensively. i'd rather not rehash it
all. in brief summary, i wholeheartedly disagree that the "scope" concept
in the servlet environment is at all compatible with your suggested "scope"
concept in dvsl. Remember, the whole point of my redesign was to allow for
many types of tools and toolinfos to go with them. If you feel we need an
another ToolInfo for DVSL tools, then please implement it separately from
the ServletToolInfo. It's really quite easy to do so. You are trying to
hard to combine to very different concepts of 'scope', and the effort is
unnecessary.
> In fact, no part of the class
> implementation is dependent on the Servlet API.
a class need not interface directly with the servlet api to be tied to the
servlet environment.
> Assume that I want to implement
> a toolbox manager for DVSL. In such an environment the scopes "request"
> and "application" make perfect sense. I see two possible resolutions:
> - Rename the class to ScopedToolInfo
> - Merge ServletToolInfo and ContextToolInfo and name the class
ContextToolInfo.
> I actually don't see an advantage of having two classes instead of
one.
> Maybe I overlook something?
yes, if you don't want to use XMLToolboxManager directly, then you can
simply implement a DVSLToolInfo and extend XMLToolboxManager to handle your
dvsl tools as you desire.
and why on earth would you want to merge ServletToolInfo into
ContextToolInfo?!? I'm sorry, but scope data does NOT belong in
ContextToolInfo.
> - ServletToolboxManager.getToolboxContext(): The instantiation of
> session tools should be synchronized, otherwise it might happen that
> the session-scoped tools are instantiated multiple times for the same
> session.
this too has been discussed at length. i think it's an incredibly paranoid
thing to do. if done correctly, it wouldn't be too much of a performance
hit, but IMO, if the current design is problematic for a tool designer, it
is the fault of their tool design, not the fault of the toolbox manager.
anyway, you seem stuck on the idea, and i can't stop you from doing it. so
do what you will, i'm tired of arguing about it.
> - I am quite uncomfortable with the proposed init method of ContextTool.
>
> public void init(Object initData);
>
> This is virtually moving us back to C-times where we worked with
pointers
> and suffered from all kind of related problems. The interface is
basically
> specified through the documentation. Yes, this approach
> keeps the interface between tools and the toolbox manager simple. But,
> the price is a problematic, underspecified, error-prone interface.
That's
> too high a price.
Really? I'll be sure to pass that on to Turbine-land where this has worked
great for their PullService for quite some time now. Someone should warn
them of their impending doom! :-) ok, maybe that's a little dramatic...
And where do you get this "problematic, underspecified, error-prone" stuff?
I see no problems (remember, i've already implemented and tested this code
and it worked great!). I think it is exactly as specified as it ought to
be. If we get any more specific, we not only lose simplicity, but also
flexibility. One of my primary goals in rewriting things this way was to
make it easy to extend the ToolboxManager concept to other environments, and
I don't want to go making assumptions about the nature of those environments
and what init data they might use or need. And as for "error-prone", huh?
i don't get that at all.
> Especially since we are not talking about very many
> different init-cases. Currently we have identified two cases:
> - Tools that need access to the servlet environment
> - Tools that need access to the Velocity context
no, i counted three. those that need the ServletContext, the ViewContext,
and just a Context. and if you missed one already, what about all the
possible init data people might want that we haven't even thought of yet?
you were the one who challenged me to think bigger and get outside the
servlet/vvs box. allow me to exhort you to do the same...
> I really think we should go the extra mile and handle these two cases
> with two specific interfaces.
I really think you're really wrong. That extra mile will not only make
things more work for us, but it will make more work for others who want to
make use of this ToolboxManager concept.
> Nathan wrote:
> > (Gabe, if you would really prefer to call this "ViewTool", I can live
with
> > it. But i still think ContextTool will be more meaningful to users.)
>
> I really would prefer ViewTool. From talking to people, my experience
> is that ViewTool is more intuitive than ContextTool.
your experience perhaps, but not mine. i've been lurking on the velocity
lists for well over a year and never heard the term 'view tool' until you
committed that change to the veltools project.
> Furthermore, there is nothing about these tools that is specific to
> the context.
? so it doesn't mean anything to you that the whole purpose of these tools
is to be placed in the velocity context?
> Much more, they are specific to the view layer. If you
> consider a situation where the same tool is used with multiple view
> technologies, then 'context tool' seems quite inappropriate.
how so? i think you ought to look up the word 'context' in an english
dictionary...
the tools are found in the velocity context, and the tools' behavior is
meant to vary based on contextual information either passed in by the
template, or thru the init() method.
i think you are afflicted with the misconception that the term 'ContextTool'
was derived from some connection to the javax.servlet.ServletContext. let
me assure, that is not at all the case.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] WebappLoader not loading
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/3/02 10:26 AM, "Tim Colson" <tc...@cisco.com> wrote:
> Gabe -
>
> [Gabriel wrote]
>> Your mail contains the output of velocity.log. Actually our
>> VelocityViewServlet implementation does not produce any
>> velocity.log. Instead the log output is redirected to the log
>> of the servlet container.
>
> I guarantee, it does produce the "velocity.log" file. This is running in
> tomcat, but note that it is started up slightly differently than a
> standalone server. It is run as a cmd line app, with a specific
> classpath, and a specific server.xml config that sets the context path
> to the project 'content' directory.
>
> Incidentally(?) I've also noticed that sometimes AvalonKit is used, and
> sometimes log4j. Log4J is always in the classpath, so I can only guess
> that this is because of trying different versions of the VelocityXXX.jar
> w/ and w/o dependancies.
Yes - that makes sense.
>
> And I've also noticed that while the init mesg. are sent to
> velocity.log, the toolbox startup mesgs. appear to be going to stdout.
>
This is strange. (Not the stdout - that might be just interim lazyness...)
If the config is right, then it should be going to servlet log. It uses the
ServletLogger (or whatever) and I know that works very well. I use it a
lot.
Can you send us the velocity.log to show us what is going on?
>
>> Now, this leads me to the
>> conclusion that you modified/overwrote method initVelocity()
>> of VelocityViewServlet.
> Nope. The full text of the LayoutVelocityViewServlet was included - I
> only overrode mergeTemplate(). That's all, truly.
>
>> That is not a problem per se, but in
>> that same method is the code to load the WebAppLoader. Please
>> verify that this code is still there.
> The code is still there. But I also stepped back and tried using just
> the VelocityViewServlet and still had the same problem with webappLoader
> not initializing.
>
>> If the WebAppLoader is successfully loaded, it produces the
>> following log output:
> Yeah...I've been trying to figure out what magic it takes to get that
> back. The weird thing is that I did have it running, but I've tried
> quite a few combinations without success.
>
> I've tried using the jars from the velstruts/WEB-INF/lib as well as
> nightly builds from both velocity and velocity-tools. I noticed that the
> velocity-1.3XX.jar is different between the two.
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] WebappLoader not loading
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/6/02 2:40 PM, "Tim Colson" <tc...@cisco.com> wrote:
> Aside - reading/deleting/gritting-my-teeth over 180 posts from the last
> 48 hours proved only that some people can be such choads, and despite
> being a fan of free uncensored speech, I wonder if this list can
> automagically filter out any post with a short-list of 4 letter words?
Like 'XSLT'?
:)
>
> Anyway - on to the thread I started :-) It's mostly just an FYI trail in
> case others find themselves with the same odd situation.
>
>> I now have the 'old' version of my app running again
>> using Veltools and webappLoader, so I'll start going piece by
>> piece to see what's different between this app and the one
>> that isn't loading correctly.
>
> I pulled my hair out on this one for quite a while, and finally decided
> to change web.xml to load the Velocity servlet FIRST, before our custom
> extended Struts servlet. That did the trick -- the log WebappLoader
> loads, logging happens, but 'velocity.log' file is NOT created.
I can't understand why that would make a difference....
> I'm not sure of the real culprit, but I'll reply again if I do find it.
>
> Cheers,
> Tim
> Oh, and I still like '&' for concat <grin>
:P
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Veltools] WebappLoader not loading
Posted by Tim Colson <tc...@cisco.com>.
Aside - reading/deleting/gritting-my-teeth over 180 posts from the last
48 hours proved only that some people can be such choads, and despite
being a fan of free uncensored speech, I wonder if this list can
automagically filter out any post with a short-list of 4 letter words?
Anyway - on to the thread I started :-) It's mostly just an FYI trail in
case others find themselves with the same odd situation.
> I now have the 'old' version of my app running again
> using Veltools and webappLoader, so I'll start going piece by
> piece to see what's different between this app and the one
> that isn't loading correctly.
I pulled my hair out on this one for quite a while, and finally decided
to change web.xml to load the Velocity servlet FIRST, before our custom
extended Struts servlet. That did the trick -- the log WebappLoader
loads, logging happens, but 'velocity.log' file is NOT created.
I'm not sure of the real culprit, but I'll reply again if I do find it.
Cheers,
Tim
Oh, and I still like '&' for concat <grin>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Veltools] WebappLoader not loading
Posted by Tim Colson <tc...@cisco.com>.
FYI - I now have the 'old' version of my app running again using
Veltools and webappLoader, so I'll start going piece by piece to see
what's different between this app and the one that isn't loading
correctly.
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Veltools] WebappLoader not loading
Posted by Tim Colson <tc...@cisco.com>.
Gabe -
[Gabriel wrote]
> Your mail contains the output of velocity.log. Actually our
> VelocityViewServlet implementation does not produce any
> velocity.log. Instead the log output is redirected to the log
> of the servlet container.
I guarantee, it does produce the "velocity.log" file. This is running in
tomcat, but note that it is started up slightly differently than a
standalone server. It is run as a cmd line app, with a specific
classpath, and a specific server.xml config that sets the context path
to the project 'content' directory.
Incidentally(?) I've also noticed that sometimes AvalonKit is used, and
sometimes log4j. Log4J is always in the classpath, so I can only guess
that this is because of trying different versions of the VelocityXXX.jar
w/ and w/o dependancies.
And I've also noticed that while the init mesg. are sent to
velocity.log, the toolbox startup mesgs. appear to be going to stdout.
> Now, this leads me to the
> conclusion that you modified/overwrote method initVelocity()
> of VelocityViewServlet.
Nope. The full text of the LayoutVelocityViewServlet was included - I
only overrode mergeTemplate(). That's all, truly.
> That is not a problem per se, but in
> that same method is the code to load the WebAppLoader. Please
> verify that this code is still there.
The code is still there. But I also stepped back and tried using just
the VelocityViewServlet and still had the same problem with webappLoader
not initializing.
> If the WebAppLoader is successfully loaded, it produces the
> following log output:
Yeah...I've been trying to figure out what magic it takes to get that
back. The weird thing is that I did have it running, but I've tried
quite a few combinations without success.
I've tried using the jars from the velstruts/WEB-INF/lib as well as
nightly builds from both velocity and velocity-tools. I noticed that the
velocity-1.3XX.jar is different between the two.
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] WebappLoader not loading
Posted by Gabriel Sidler <si...@teamup.ch>.
Tim,
here a few guesses:
Your mail contains the output of velocity.log. Actually our VelocityViewServlet
implementation does not produce any velocity.log. Instead the log output
is redirected to the log of the servlet container. Now, this leads me to
the conclusion that you modified/overwrote method initVelocity() of
VelocityViewServlet. That is not a problem per se, but in that same method
is the code to load the WebAppLoader. Please verify that this code is still
there.
If the WebAppLoader is successfully loaded, it produces the following
log output:
[2002/04/04 14:57:47] Velocity [info] Resource Loader Instantiated: org.apache.velocity.tools.view.servlet.WebappLoader
[2002/04/04 14:57:47] Velocity [info] WebappLoader : initialization starting.
[2002/04/04 14:57:47] Velocity [info] WebappLoader : initialization complete.
Gabe
Tim Colson wrote:
> Say folks -
>
> I have the velstruts demo running just fine. I then managed to pull
> the necessary bits from the demo into an existing app and get that
> running. Next I extended VelocityViewServlet into a version that does a
> two-pass render (aka LayoutVelocityViewServlet) and that ran (source
> copied at the bottom).
>
> But now I can't seem to get veltools working in another app. What's
> worse, the original veltools app won't run either. Aaaaack. (I honestly
> don't know what I changed that caused the working app to go bad, I have
> tried to step back, but without success.)
>
> The only thing I can find that looks wrong is that the WebappLoader is
> not initializing in my app.
>
> I'm using Tomcat 3.2.1 supplemented with JAXP1.1, crimson.jar -- started
> up from inside my IDE (tomcat startup shown directly below).
>
> I also included the error I get when the view attempts to render my *.vm
> file, and a snippet from the WORKING velstruts demo app log.
>
> Helpful suggestions are appreciated. ;-)
>
> Cheers,
> Tim
> -----------------
>
> Tomcat Startup:
> D:\java\jdk1.3.1_02\bin\javaw.exe
> -classpath "D:\java\jdk1.3.1_02\jre\lib\rt.jar;
> D:\java\jdk1.3.1_02\lib\tools.jar;
> <APP_ROOT>\WEB-INF\classes;
> <APP_ROOT>\WEB-INF\properties;
> <APP_ROOT>\WEB-INF\lib\velocity-dep-1.3-dev.jar;
> <APP_ROOT>\WEB-INF\lib\commons-beanutils.jar;
> <APP_ROOT>\WEB-INF\lib\commons-collections.jar;
> <APP_ROOT>\WEB-INF\lib\commons-digester.jar;
> <APP_ROOT>\WEB-INF\lib\dom4j.jar;
> <APP_ROOT>\WEB-INF\lib\velocity-tools-library-0.1.jar;
> <APP_ROOT>\WEB-INF\lib\velocity-tools-struts-0.7.jar;
> <APP_ROOT>\WEB-INF\lib\velocity-tools-view-0.6.jar;
> <APP_ROOT>\WEB-INF\lib\veltag-0.01-dev.jar;
> <APP_ROOT>\WEB-INF\lib\jakarta-regexp-1.2.jar;
> <APP_ROOT>\WEB-INF\lib\jakarta-oro-2.0.5.jar;
> <APP_ROOT>\WEB-INF\lib\jivefw.jar;
> <APP_ROOT>\WEB-INF\lib\log4j.jar;
> <APP_ROOT>\WEB-INF\lib\struts.jar;
> <APP_ROOT>\WEB-INF\lib\Struts_Validator-20010702.jar;
> D:\java\lib\junit.jar;
> D:\java\lib\activation.jar;
> D:\java\lib\mail.jar;
> D:\java\jakarta-tomcat-3.2.1\lib\servlet.jar;
> D:\Java\jakarta-tomcat-3.2.1\lib\webserver.jar;
> D:\Java\jakarta-tomcat-3.2.1\lib\jaxp.jar;
> D:\Java\jakarta-tomcat-3.2.1\lib\jasper.jar;
> D:\java\jakarta-tomcat-3.2.1\lib\crimson.jar;
> C:\Oracle\Ora81\jdbc\lib\classes12.zip"
> org.apache.tomcat.startup.Tomcat
> -config <APP_ROOT>\conf\server.xml
>
>
>
> VELSTRUTS DEMO - WORKING
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
> **************************************************************
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Starting
> Jakarta Velocity v1.3-dev
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
> RuntimeInstance initializing.
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
> Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
> ResourceManager initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Resource
> Loader Instantiated: org.apache.velocity.tools.view.servlet.WebappLoader
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] WebappLoader
> : initialization starting.
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] WebappLoader
> : initialization complete.
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
> ResourceCache : initialized. (class
> org.apache.velocity.runtime.resource.ResourceCacheImpl)
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
> ResourceManager initialization complete.
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
> System Directive: org.apache.velocity.runtime.directive.Literal
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
> System Directive: org.apache.velocity.runtime.directive.Macro
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
> System Directive: org.apache.velocity.runtime.directive.Parse
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
> System Directive: org.apache.velocity.runtime.directive.Include
> 2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
> System Directive: org.apache.velocity.runtime.directive.Foreach
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Created: 20
> parsers.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : initialization starting.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : adding VMs from VM library template : /WEB-INF/VM_global_library.vm
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : added new VM : #errorMarkup( ) : source =
> /WEB-INF/VM_global_library.vm
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : added new VM : #errorMarkupForProperty( property ) : source =
> /WEB-INF/VM_global_library.vm
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info]
> ResourceManager : found /WEB-INF/VM_global_library.vm with loader
> org.apache.velocity.tools.view.servlet.WebappLoader
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : VM library template macro registration complete.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : allowInline = true : VMs can be defined inline in templates
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : allowInlineToOverride = false : VMs defined inline may NOT replace
> previous VM definitions
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : allowInlineLocal = false : VMs defined inline will be global in scope
> if allowed.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : messages on : VM system will output logging messages
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : autoload off : VM system will not automatically reload global library
> macros
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
> : initialization complete.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocity
> successfully started.
> 2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Using
> toolbox configuration file '/WEB-INF/toolbox.xml'
> 2002-05-02 02:34:01 - path="/velstruts" :ServletToolboxManager:
> Initializing the toolbox...
> 2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Loading
> tool
> 2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager:
> Context key: toolLoader
> 2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Class:
> org.apache.velocity.tools.tools.ToolLoader
> 2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Life
> cycle:
> 2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Known
> interface: LogEnabledViewTool
> ----
>
> Resource not found Error when trying to process the action forward.
>
> VelocityServlet : Error processing the template
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource
> '/vm/SearchResults.vm'org.apache.velocity.exception.ResourceNotFoundExce
> ption: Unable to find resource '/vm/SearchResults.vm'
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(Re
> sourceManagerImpl.java:502)
> at
> org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(Res
> ourceManagerImpl.java:386)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.
> java:812)
> at
> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.
> java:794)
> at
> org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleto
> n.java:337)
> at
> org.apache.velocity.servlet.VelocityServlet.getTemplate(VelocityServlet.
> java:524)
> at
> org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest
> (VelocityViewServlet.java:272)
> at
> org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServlet.ja
> va:356)
> at
> org.apache.velocity.servlet.VelocityServlet.doPost(VelocityServlet.java:
> 326)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
> at org.apache.tomcat.core.Handler.service(Handler.java:286)
> at
> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
> at
> org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcher
> Impl.java:194)
> at
> org.apache.struts.action.ActionServlet.processActionForward(ActionServle
> t.java:1758)
> at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
> at
> org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
> at
> com.cisco.hrit.core.servlet.ServletBase.doGet(ServletBase.java:78)
> at
> com.cisco.hrit.core.servlet.ServletBase.doPost(ServletBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> at
> com.cisco.hrit.core.servlet.ServletBase.service(ServletBase.java:177)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
> at org.apache.tomcat.core.Handler.service(Handler.java:286)
> at
> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav
> a:797)
> at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
> at
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(H
> ttpConnectionHandler.java:210)
> at
> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416
> )
> at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49
> 8)
>
> ---
>
> velocity.log file contents... notice that WebappLoader isn't present.
>
> Thu May 02 15:23:34 PDT 2002 [debug] AvalonLogSystem initialized using
> logfile 'velocity.log'
> Thu May 02 15:23:34 PDT 2002 [info]
> **************************************************************
> Thu May 02 15:23:34 PDT 2002 [info] Starting Jakarta Velocity v1.3-dev
> Thu May 02 15:23:34 PDT 2002 [info] RuntimeInstance initializing.
> Thu May 02 15:23:34 PDT 2002 [info] Default Properties File:
> org\apache\velocity\runtime\defaults\velocity.properties
> Thu May 02 15:23:34 PDT 2002 [info] Trying to use logger class
> org.apache.velocity.runtime.log.AvalonLogSystem
> Thu May 02 15:23:34 PDT 2002 [info] Using logger class
> org.apache.velocity.runtime.log.AvalonLogSystem
> Thu May 02 15:23:34 PDT 2002 [info] Default ResourceManager
> initializing. (class
> org.apache.velocity.runtime.resource.ResourceManagerImpl)
> Thu May 02 15:23:34 PDT 2002 [info] Resource Loader Instantiated:
> org.apache.velocity.runtime.resource.loader.FileResourceLoader
> Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader :
> initialization starting.
> Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader : adding path
> '.'
> Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader :
> initialization complete.
> Thu May 02 15:23:34 PDT 2002 [info] ResourceCache : initialized.
> (class org.apache.velocity.runtime.resource.ResourceCacheImpl)
> Thu May 02 15:23:34 PDT 2002 [info] Default ResourceManager
> initialization complete.
> Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
> org.apache.velocity.runtime.directive.Literal
> Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
> org.apache.velocity.runtime.directive.Macro
> Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
> org.apache.velocity.runtime.directive.Parse
> Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
> org.apache.velocity.runtime.directive.Include
> Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
> org.apache.velocity.runtime.directive.Foreach
> Thu May 02 15:23:34 PDT 2002 [info] Created: 20 parsers.
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : initialization
> starting.
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : adding VMs from VM
> library template : VM_global_library.vm
> Thu May 02 15:23:34 PDT 2002 [error] ResourceManager : unable to find
> resource 'VM_global_library.vm' in any resource loader.
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : error using VM
> library template VM_global_library.vm :
> org.apache.velocity.exception.ResourceNotFoundException: Unable to find
> resource 'VM_global_library.vm'
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : VM library template
> macro registration complete.
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : allowInline = true :
> VMs can be defined inline in templates
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro :
> allowInlineToOverride = false : VMs defined inline may NOT replace
> previous VM definitions
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : allowInlineLocal =
> false : VMs defined inline will be global in scope if allowed.
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : messages on : VM
> system will output logging messages
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : autoload off : VM
> system will not automatically reload global library macros
> Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : initialization
> complete.
> Thu May 02 15:23:34 PDT 2002 [info] Velocity successfully started.
> Thu May 02 15:23:34 PDT 2002 [info] Using toolbox configuration file
> '/WEB-INF/toolbox.xml'
> Thu May 02 15:23:34 PDT 2002 [info] Toolbox setup complete.
>
> ---
> // LayoutVelocityViewServlet
>
> package com.cisco.hrit;
>
> import org.apache.velocity.Template;
> import org.apache.velocity.context.Context;
> import org.apache.velocity.exception.MethodInvocationException;
> import org.apache.velocity.exception.ParseErrorException;
> import org.apache.velocity.exception.ResourceNotFoundException;
> import org.apache.velocity.tools.view.servlet.VelocityViewServlet;
>
> import javax.servlet.http.HttpServletResponse;
> import java.io.IOException;
> import java.io.StringWriter;
> import java.io.UnsupportedEncodingException;
>
> public class LayoutVelocityViewServlet extends VelocityViewServlet {
>
> protected void mergeTemplate (Template template, Context context,
> HttpServletResponse response)
> throws ResourceNotFoundException, ParseErrorException,
> MethodInvocationException, IOException,
> UnsupportedEncodingException, Exception {
>
> // Check for a layout
> String layoutFile = (String) context.get("LAYOUT");
>
> if (layoutFile != null) {
> // Load up the layout template
> Template layoutTemplate = null;
>
> try {
> layoutTemplate = getTemplate(layoutFile);
> } catch (ResourceNotFoundException rnfe) {
> // couldn't find the template
> System.out.println("rnfe = " + rnfe);
> } catch (ParseErrorException pee) {
> // syntax error : problem parsing the template
> System.out.println("pee = " + pee);
> } catch (MethodInvocationException mie) {
> // something invoked in the template threw an exception
> System.out.println("mie = " + mie);
> } catch (Exception e) {
> System.out.println("e = " + e);
> }
>
> // Render the first pass, i.e. body content
> StringWriter sw = new StringWriter();
> template.merge(context, sw);
> // Add the resulting content to the context
> context.put("CONTENT", sw.toString());
> // Render the second pass, i.e. layout
> super.mergeTemplate(layoutTemplate, context, response);
> } else {
> // no layout specified, so just send the template specified
> directly to the user.
> super.mergeTemplate(template, context, response);
> }
>
> }
> }
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Veltools] WebappLoader not loading
Posted by Tim Colson <tc...@cisco.com>.
Say folks -
I have the velstruts demo running just fine. I then managed to pull
the necessary bits from the demo into an existing app and get that
running. Next I extended VelocityViewServlet into a version that does a
two-pass render (aka LayoutVelocityViewServlet) and that ran (source
copied at the bottom).
But now I can't seem to get veltools working in another app. What's
worse, the original veltools app won't run either. Aaaaack. (I honestly
don't know what I changed that caused the working app to go bad, I have
tried to step back, but without success.)
The only thing I can find that looks wrong is that the WebappLoader is
not initializing in my app.
I'm using Tomcat 3.2.1 supplemented with JAXP1.1, crimson.jar -- started
up from inside my IDE (tomcat startup shown directly below).
I also included the error I get when the view attempts to render my *.vm
file, and a snippet from the WORKING velstruts demo app log.
Helpful suggestions are appreciated. ;-)
Cheers,
Tim
-----------------
Tomcat Startup:
D:\java\jdk1.3.1_02\bin\javaw.exe
-classpath "D:\java\jdk1.3.1_02\jre\lib\rt.jar;
D:\java\jdk1.3.1_02\lib\tools.jar;
<APP_ROOT>\WEB-INF\classes;
<APP_ROOT>\WEB-INF\properties;
<APP_ROOT>\WEB-INF\lib\velocity-dep-1.3-dev.jar;
<APP_ROOT>\WEB-INF\lib\commons-beanutils.jar;
<APP_ROOT>\WEB-INF\lib\commons-collections.jar;
<APP_ROOT>\WEB-INF\lib\commons-digester.jar;
<APP_ROOT>\WEB-INF\lib\dom4j.jar;
<APP_ROOT>\WEB-INF\lib\velocity-tools-library-0.1.jar;
<APP_ROOT>\WEB-INF\lib\velocity-tools-struts-0.7.jar;
<APP_ROOT>\WEB-INF\lib\velocity-tools-view-0.6.jar;
<APP_ROOT>\WEB-INF\lib\veltag-0.01-dev.jar;
<APP_ROOT>\WEB-INF\lib\jakarta-regexp-1.2.jar;
<APP_ROOT>\WEB-INF\lib\jakarta-oro-2.0.5.jar;
<APP_ROOT>\WEB-INF\lib\jivefw.jar;
<APP_ROOT>\WEB-INF\lib\log4j.jar;
<APP_ROOT>\WEB-INF\lib\struts.jar;
<APP_ROOT>\WEB-INF\lib\Struts_Validator-20010702.jar;
D:\java\lib\junit.jar;
D:\java\lib\activation.jar;
D:\java\lib\mail.jar;
D:\java\jakarta-tomcat-3.2.1\lib\servlet.jar;
D:\Java\jakarta-tomcat-3.2.1\lib\webserver.jar;
D:\Java\jakarta-tomcat-3.2.1\lib\jaxp.jar;
D:\Java\jakarta-tomcat-3.2.1\lib\jasper.jar;
D:\java\jakarta-tomcat-3.2.1\lib\crimson.jar;
C:\Oracle\Ora81\jdbc\lib\classes12.zip"
org.apache.tomcat.startup.Tomcat
-config <APP_ROOT>\conf\server.xml
VELSTRUTS DEMO - WORKING
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
**************************************************************
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Starting
Jakarta Velocity v1.3-dev
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
RuntimeInstance initializing.
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
Properties File:
org\apache\velocity\runtime\defaults\velocity.properties
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Resource
Loader Instantiated: org.apache.velocity.tools.view.servlet.WebappLoader
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] WebappLoader
: initialization starting.
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] WebappLoader
: initialization complete.
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info]
ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Default
ResourceManager initialization complete.
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
System Directive: org.apache.velocity.runtime.directive.Literal
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
System Directive: org.apache.velocity.runtime.directive.Macro
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
System Directive: org.apache.velocity.runtime.directive.Parse
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
System Directive: org.apache.velocity.runtime.directive.Include
2002-05-02 02:34:00 - path="/velstruts" : Velocity [info] Loaded
System Directive: org.apache.velocity.runtime.directive.Foreach
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Created: 20
parsers.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: initialization starting.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: adding VMs from VM library template : /WEB-INF/VM_global_library.vm
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: added new VM : #errorMarkup( ) : source =
/WEB-INF/VM_global_library.vm
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: added new VM : #errorMarkupForProperty( property ) : source =
/WEB-INF/VM_global_library.vm
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info]
ResourceManager : found /WEB-INF/VM_global_library.vm with loader
org.apache.velocity.tools.view.servlet.WebappLoader
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: VM library template macro registration complete.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: allowInline = true : VMs can be defined inline in templates
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: allowInlineToOverride = false : VMs defined inline may NOT replace
previous VM definitions
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: allowInlineLocal = false : VMs defined inline will be global in scope
if allowed.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: messages on : VM system will output logging messages
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: autoload off : VM system will not automatically reload global library
macros
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocimacro
: initialization complete.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Velocity
successfully started.
2002-05-02 02:34:01 - path="/velstruts" : Velocity [info] Using
toolbox configuration file '/WEB-INF/toolbox.xml'
2002-05-02 02:34:01 - path="/velstruts" :ServletToolboxManager:
Initializing the toolbox...
2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Loading
tool
2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager:
Context key: toolLoader
2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Class:
org.apache.velocity.tools.tools.ToolLoader
2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Life
cycle:
2002-05-02 02:34:02 - path="/velstruts" :ServletToolboxManager: Known
interface: LogEnabledViewTool
----
Resource not found Error when trying to process the action forward.
VelocityServlet : Error processing the template
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource
'/vm/SearchResults.vm'org.apache.velocity.exception.ResourceNotFoundExce
ption: Unable to find resource '/vm/SearchResults.vm'
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource(Re
sourceManagerImpl.java:502)
at
org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource(Res
ourceManagerImpl.java:386)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.
java:812)
at
org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.
java:794)
at
org.apache.velocity.runtime.RuntimeSingleton.getTemplate(RuntimeSingleto
n.java:337)
at
org.apache.velocity.servlet.VelocityServlet.getTemplate(VelocityServlet.
java:524)
at
org.apache.velocity.tools.view.servlet.VelocityViewServlet.handleRequest
(VelocityViewServlet.java:272)
at
org.apache.velocity.servlet.VelocityServlet.doRequest(VelocityServlet.ja
va:356)
at
org.apache.velocity.servlet.VelocityServlet.doPost(VelocityServlet.java:
326)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.facade.RequestDispatcherImpl.forward(RequestDispatcher
Impl.java:194)
at
org.apache.struts.action.ActionServlet.processActionForward(ActionServle
t.java:1758)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
at
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:491)
at
com.cisco.hrit.core.servlet.ServletBase.doGet(ServletBase.java:78)
at
com.cisco.hrit.core.servlet.ServletBase.doPost(ServletBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
com.cisco.hrit.core.servlet.ServletBase.service(ServletBase.java:177)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav
a:797)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(H
ttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416
)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49
8)
---
velocity.log file contents... notice that WebappLoader isn't present.
Thu May 02 15:23:34 PDT 2002 [debug] AvalonLogSystem initialized using
logfile 'velocity.log'
Thu May 02 15:23:34 PDT 2002 [info]
**************************************************************
Thu May 02 15:23:34 PDT 2002 [info] Starting Jakarta Velocity v1.3-dev
Thu May 02 15:23:34 PDT 2002 [info] RuntimeInstance initializing.
Thu May 02 15:23:34 PDT 2002 [info] Default Properties File:
org\apache\velocity\runtime\defaults\velocity.properties
Thu May 02 15:23:34 PDT 2002 [info] Trying to use logger class
org.apache.velocity.runtime.log.AvalonLogSystem
Thu May 02 15:23:34 PDT 2002 [info] Using logger class
org.apache.velocity.runtime.log.AvalonLogSystem
Thu May 02 15:23:34 PDT 2002 [info] Default ResourceManager
initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
Thu May 02 15:23:34 PDT 2002 [info] Resource Loader Instantiated:
org.apache.velocity.runtime.resource.loader.FileResourceLoader
Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader :
initialization starting.
Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader : adding path
'.'
Thu May 02 15:23:34 PDT 2002 [info] FileResourceLoader :
initialization complete.
Thu May 02 15:23:34 PDT 2002 [info] ResourceCache : initialized.
(class org.apache.velocity.runtime.resource.ResourceCacheImpl)
Thu May 02 15:23:34 PDT 2002 [info] Default ResourceManager
initialization complete.
Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
org.apache.velocity.runtime.directive.Literal
Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
org.apache.velocity.runtime.directive.Macro
Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
org.apache.velocity.runtime.directive.Parse
Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
org.apache.velocity.runtime.directive.Include
Thu May 02 15:23:34 PDT 2002 [info] Loaded System Directive:
org.apache.velocity.runtime.directive.Foreach
Thu May 02 15:23:34 PDT 2002 [info] Created: 20 parsers.
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : initialization
starting.
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : adding VMs from VM
library template : VM_global_library.vm
Thu May 02 15:23:34 PDT 2002 [error] ResourceManager : unable to find
resource 'VM_global_library.vm' in any resource loader.
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : error using VM
library template VM_global_library.vm :
org.apache.velocity.exception.ResourceNotFoundException: Unable to find
resource 'VM_global_library.vm'
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : VM library template
macro registration complete.
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : allowInline = true :
VMs can be defined inline in templates
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro :
allowInlineToOverride = false : VMs defined inline may NOT replace
previous VM definitions
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : allowInlineLocal =
false : VMs defined inline will be global in scope if allowed.
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : messages on : VM
system will output logging messages
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : autoload off : VM
system will not automatically reload global library macros
Thu May 02 15:23:34 PDT 2002 [info] Velocimacro : initialization
complete.
Thu May 02 15:23:34 PDT 2002 [info] Velocity successfully started.
Thu May 02 15:23:34 PDT 2002 [info] Using toolbox configuration file
'/WEB-INF/toolbox.xml'
Thu May 02 15:23:34 PDT 2002 [info] Toolbox setup complete.
---
// LayoutVelocityViewServlet
package com.cisco.hrit;
import org.apache.velocity.Template;
import org.apache.velocity.context.Context;
import org.apache.velocity.exception.MethodInvocationException;
import org.apache.velocity.exception.ParseErrorException;
import org.apache.velocity.exception.ResourceNotFoundException;
import org.apache.velocity.tools.view.servlet.VelocityViewServlet;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.StringWriter;
import java.io.UnsupportedEncodingException;
public class LayoutVelocityViewServlet extends VelocityViewServlet {
protected void mergeTemplate (Template template, Context context,
HttpServletResponse response)
throws ResourceNotFoundException, ParseErrorException,
MethodInvocationException, IOException,
UnsupportedEncodingException, Exception {
// Check for a layout
String layoutFile = (String) context.get("LAYOUT");
if (layoutFile != null) {
// Load up the layout template
Template layoutTemplate = null;
try {
layoutTemplate = getTemplate(layoutFile);
} catch (ResourceNotFoundException rnfe) {
// couldn't find the template
System.out.println("rnfe = " + rnfe);
} catch (ParseErrorException pee) {
// syntax error : problem parsing the template
System.out.println("pee = " + pee);
} catch (MethodInvocationException mie) {
// something invoked in the template threw an exception
System.out.println("mie = " + mie);
} catch (Exception e) {
System.out.println("e = " + e);
}
// Render the first pass, i.e. body content
StringWriter sw = new StringWriter();
template.merge(context, sw);
// Add the resulting content to the context
context.put("CONTENT", sw.toString());
// Render the second pass, i.e. layout
super.mergeTemplate(layoutTemplate, context, response);
} else {
// no layout specified, so just send the template specified
directly to the user.
super.mergeTemplate(template, context, response);
}
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Gabriel Sidler <si...@teamup.ch>.
Geir Magnusson Jr. wrote:
> On 5/2/02 5:17 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>
>
>>Geir Magnusson Jr. wrote:
>>
>>
>>>On 5/2/02 4:45 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>>>
>>>
>>>
>>>>Nathan,
>>>>I finally got around to study your latest proposal regarding the tool
>>>>management. Overall I like the approach and think it is a good basis
>>>>to move on.
>>>>
>>>>I'd like to make a few remarks/suggestions:
>>>>
>>>>- Your proposed DTD for the toolbox configuration makes good sense
>>>>to me. The minor exception is that the 'scope' element seems to be
>>>>missing. Or, am I missing something?
>>>>
>>>>
>>>>
>>>What does scope mean in a toolbox?
>>>
>>
>>Defines the life cycle of a tool. Values are 'request', 'session' and
>>'application'.
>>
>>
>
> I have no idea what that means outside of Servlet-land.
First of all, scope is and has been misleading in this context. I am
not sure if 'life span' or 'life cycle' of a tool would be more clear.
My view is this: As soon as you process more than one template within an
application, you are confronted with the design decision how to handle
the instantiation of view tools. Are you creating one tool instance and
reuse it for all templates OR are you recreating tool instances for every
template that is being processed? The answer to that question is influenced
by aspects like performance, thread safety of tools, implementation effort
required, etc.
In that sense, the concept of scope/life span/life cycle can be seen as
applicable not only to the servlet environment but to virtually any
environment where Velocity templates are being processed. In some environments
the life span of tools is hard-coded (e.g. DVSL), in others its configurable
(e.g. VelocityViewServlet).
I agree that these are somewhat theoretical considerations, but since
we are working on a library of reusalble view tools I think it is
helpful to try to generalize the involved concepts.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On 5/2/02 5:17 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Geir Magnusson Jr. wrote:
>
>> On 5/2/02 4:45 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>>
>>
>>> Nathan,
>>> I finally got around to study your latest proposal regarding the tool
>>> management. Overall I like the approach and think it is a good basis
>>> to move on.
>>>
>>> I'd like to make a few remarks/suggestions:
>>>
>>> - Your proposed DTD for the toolbox configuration makes good sense
>>> to me. The minor exception is that the 'scope' element seems to be
>>> missing. Or, am I missing something?
>>>
>>>
>>
>> What does scope mean in a toolbox?
>
>
> Defines the life cycle of a tool. Values are 'request', 'session' and
> 'application'.
>
I have no idea what that means outside of Servlet-land.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by Gabriel Sidler <si...@teamup.ch>.
Geir Magnusson Jr. wrote:
> On 5/2/02 4:45 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
>
>
>>Nathan,
>>I finally got around to study your latest proposal regarding the tool
>>management. Overall I like the approach and think it is a good basis
>>to move on.
>>
>>I'd like to make a few remarks/suggestions:
>>
>>- Your proposed DTD for the toolbox configuration makes good sense
>>to me. The minor exception is that the 'scope' element seems to be
>>missing. Or, am I missing something?
>>
>>
>
> What does scope mean in a toolbox?
Defines the life cycle of a tool. Values are 'request', 'session' and
'application'.
Gabe
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Veltools] ToolboxManager (round 4 :-)
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/2/02 4:45 PM, "Gabriel Sidler" <si...@teamup.ch> wrote:
> Nathan,
> I finally got around to study your latest proposal regarding the tool
> management. Overall I like the approach and think it is a good basis
> to move on.
>
> I'd like to make a few remarks/suggestions:
>
> - Your proposed DTD for the toolbox configuration makes good sense
> to me. The minor exception is that the 'scope' element seems to be
> missing. Or, am I missing something?
>
What does scope mean in a toolbox?
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>