upgrading

[Charles Harvey III]

Ok.  I tried and tried and I cannot get the ServletConfig to where I
need it so
I can create a new VelocityView.  The best I can get is a ServletContext.
------------------------------------------------------------------
VelocityView velocityView = new VelocityView( getServletContext() );
Context context = velocityView.getContext( request, response );
------------------------------------------------------------------

And, looking at the code for VelocityView, when you create a new
VelocityView
with a ServletContext, it never calls the init(ServletConfig config) method.
So, the tools don't get configured.  When I do $params.get('thing') it
tells me:

   Request is null. ParameterTool must be initialized first!

So, I tried it the "standalone" way:
------------------------------------------------------------------
ToolManager manager = new ToolManager();
if( getToolboxConfigLocation() != null )
{
    manager.configure( getServletContext().getRealPath(
getToolboxConfigLocation() ) );
}
manager.setVelocityEngine( getVelocityEngine() );
Context context = manager.createContext();
------------------------------------------------------------------

And I get the same result.

One other attempt was made:
------------------------------------------------------------------
ViewToolContext context = new ViewToolContext( getVelocityEngine(),
                                               request, response,
getServletContext() );
------------------------------------------------------------------

This time, no errors.  But the tools don't work.  I see a bunch of
$link.setRelative()
all over the page.  Nothing renders.


Am I close?  Way off?  Any help is much appreciated.

Thanks again.


Charlie


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Nathan Bubna]

On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
> Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
> so
>  I can create a new VelocityView.  The best I can get is a ServletContext.

That is a bummer.  Thank you!  Seriously, this exposes a signficant
shortcoming in the plans to make it easy to integrate Tools into other
frameworks.  It also made me realize that i didn't provide proper
Filter support either.  It needs to be easier to init() a VelocityView
(whether with a ServletConfig, FilterConfig or neither).  I'll try to
set aside some time to fix that this week.  It'll mean we need to do
another beta, i'm sure, but i think it'll be well worth it.

>  ------------------------------------------------------------------
>  VelocityView velocityView = new VelocityView( getServletContext() );
>  Context context = velocityView.getContext( request, response );
>  ------------------------------------------------------------------
>
>  And, looking at the code for VelocityView, when you create a new
> VelocityView
>  with a ServletContext, it never calls the init(ServletConfig config)
> method.
>  So, the tools don't get configured.  When I do $params.get('thing') it
> tells me:
>
>   Request is null. ParameterTool must be initialized first!

Actually, this means the tools did get configured.  This just means
that the tool was never given access to the HttpServletRequest; the
tools aren't being properly initialized.

You could just precede $params.thing with $params.setRequest($request)
to make this work, but obviously that shouldn't be necessary and would
not work for tools who use configure() instead of setters.

>  So, I tried it the "standalone" way:
>  ------------------------------------------------------------------
>  ToolManager manager = new ToolManager();
>  if( getToolboxConfigLocation() != null )
>  {
>    manager.configure( getServletContext().getRealPath(
> getToolboxConfigLocation() ) );
>  }
>  manager.setVelocityEngine( getVelocityEngine() );
>  Context context = manager.createContext();
>  ------------------------------------------------------------------
>
>  And I get the same result.

As expected.  The code above has no knowledge of ServletRequests, so
it would be unable to tell tools about them.

>  One other attempt was made:
>  ------------------------------------------------------------------
>  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
>                                               request, response,
> getServletContext() );
>  ------------------------------------------------------------------
>
>  This time, no errors.  But the tools don't work.  I see a bunch of
> $link.setRelative()
>  all over the page.  Nothing renders.

That's because the ViewToolContext only knows how to find tools.  It
doesn't create them at all.

>
>  Am I close?  Way off?  Any help is much appreciated.
>

Your last example is actually headed in the right direction.
Unfortunately, since you can't use VelocityView until i fix it, it's a
little more complicated.  Here's the gist, though i'll have to leave
you to fill in the blanks for the moment:

the first goal is to create a FactoryConfiguration, then configure a
new ToolboxFactory instance with that config.  this may look something
like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
for a much more involved example):

FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
read javadoc on this!
ToolboxFactory factory = new ToolboxFactory();
factory.configure(config);

keep this factory around for the life of the app.  you only want the
code above to happen once, not on every request!

this once-per-app initialization is also a good place to create your
application-scoped toolbox and put that in the servlet context.  that
code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
and looks roughly like this:

        Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
        if (appTools != null &&
            servletContext.getAttribute(Toolbox.class.getName()) == null)
        {
            servletContext.setAttribute(Toolbox.class.getName(), appTools);
        }


with that, the application level stuff should be ready to go; now we
just need to prep some things before every request.  so, before you
create that ViewToolContext in your last example above, use your
ToolboxFactory and do the following (this code is ripped from
VelocityView.prepareToolboxes()):

        String key = Toolbox.class.getName();
        if (factory.hasTools(Scope.REQUEST)
            && request.getAttribute(key) == null)
        {
            // add request toolbox, if any
            Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
            if (reqTools != null)
            {
                request.setAttribute(key, reqTools);
            }
        }

        if (factory.hasTools("session"))
        {
             HttpSession session = request.getSession(true);
              // allow only one thread at a time
               synchronized(factory)
                {
                    if (session.getAttribute(key) == null)
                    {
                        Toolbox sessTools =
                            factory.createToolbox("session");
                        session.setAttribute(key, sessTools);
                    }
                }
            }


This creates the Toolbox instances for the current session and request
and puts them where the ViewToolContext can find them.  Once all of
the above is done, create your ViewToolContext and return that.

i think that should do the trick.  sorry this is more complicated that
i'd hoped.  i'll try and whip the VelocityView init code into
something more forgiving and get a new beta out.  Thanks for bringing
attention to this deficit. :)

>  Thanks again.
>
>
>
>
>  Charlie
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: user-unsubscribe@...
>  For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[CloD]

Le mardi 08 avril 2008 à 15:15 -0700, Nathan Bubna a écrit :

> On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
> > Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
> > so
> >  I can create a new VelocityView.  The best I can get is a ServletContext.
>
> That is a bummer.  Thank you!  Seriously, this exposes a signficant
> shortcoming in the plans to make it easy to integrate Tools into other
> frameworks.  It also made me realize that i didn't provide proper
> Filter support either.  It needs to be easier to init() a VelocityView
> (whether with a ServletConfig, FilterConfig or neither).  I'll try to
> set aside some time to fix that this week.  It'll mean we need to do
> another beta, i'm sure, but i think it'll be well worth it.

I noted this fact in http://issues.apache.org/jira/browse/VELTOOLS-94

:-)

It's some code you left apart for some reason...


  Claude

> >  ------------------------------------------------------------------
> >  VelocityView velocityView = new VelocityView( getServletContext() );
> >  Context context = velocityView.getContext( request, response );
> >  ------------------------------------------------------------------
> >
> >  And, looking at the code for VelocityView, when you create a new
> > VelocityView
> >  with a ServletContext, it never calls the init(ServletConfig config)
> > method.
> >  So, the tools don't get configured.  When I do $params.get('thing') it
> > tells me:
> >
> >   Request is null. ParameterTool must be initialized first!
>
> Actually, this means the tools did get configured.  This just means
> that the tool was never given access to the HttpServletRequest; the
> tools aren't being properly initialized.
>
> You could just precede $params.thing with $params.setRequest($request)
> to make this work, but obviously that shouldn't be necessary and would
> not work for tools who use configure() instead of setters.
>
> >  So, I tried it the "standalone" way:
> >  ------------------------------------------------------------------
> >  ToolManager manager = new ToolManager();
> >  if( getToolboxConfigLocation() != null )
> >  {
> >    manager.configure( getServletContext().getRealPath(
> > getToolboxConfigLocation() ) );
> >  }
> >  manager.setVelocityEngine( getVelocityEngine() );
> >  Context context = manager.createContext();
> >  ------------------------------------------------------------------
> >
> >  And I get the same result.
>
> As expected.  The code above has no knowledge of ServletRequests, so
> it would be unable to tell tools about them.
>
> >  One other attempt was made:
> >  ------------------------------------------------------------------
> >  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
> >                                               request, response,
> > getServletContext() );
> >  ------------------------------------------------------------------
> >
> >  This time, no errors.  But the tools don't work.  I see a bunch of
> > $link.setRelative()
> >  all over the page.  Nothing renders.
>
> That's because the ViewToolContext only knows how to find tools.  It
> doesn't create them at all.
>
> >
> >  Am I close?  Way off?  Any help is much appreciated.
> >
>
> Your last example is actually headed in the right direction.
> Unfortunately, since you can't use VelocityView until i fix it, it's a
> little more complicated.  Here's the gist, though i'll have to leave
> you to fill in the blanks for the moment:
>
> the first goal is to create a FactoryConfiguration, then configure a
> new ToolboxFactory instance with that config.  this may look something
> like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
> for a much more involved example):
>
> FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
> read javadoc on this!
> ToolboxFactory factory = new ToolboxFactory();
> factory.configure(config);
>
> keep this factory around for the life of the app.  you only want the
> code above to happen once, not on every request!
>
> this once-per-app initialization is also a good place to create your
> application-scoped toolbox and put that in the servlet context.  that
> code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
> and looks roughly like this:
>
>         Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
>         if (appTools != null &&
>             servletContext.getAttribute(Toolbox.class.getName()) == null)
>         {
>             servletContext.setAttribute(Toolbox.class.getName(), appTools);
>         }
>
>
> with that, the application level stuff should be ready to go; now we
> just need to prep some things before every request.  so, before you
> create that ViewToolContext in your last example above, use your
> ToolboxFactory and do the following (this code is ripped from
> VelocityView.prepareToolboxes()):
>
>         String key = Toolbox.class.getName();
>         if (factory.hasTools(Scope.REQUEST)
>             && request.getAttribute(key) == null)
>         {
>             // add request toolbox, if any
>             Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
>             if (reqTools != null)
>             {
>                 request.setAttribute(key, reqTools);
>             }
>         }
>
>         if (factory.hasTools("session"))
>         {
>              HttpSession session = request.getSession(true);
>               // allow only one thread at a time
>                synchronized(factory)
>                 {
>                     if (session.getAttribute(key) == null)
>                     {
>                         Toolbox sessTools =
>                             factory.createToolbox("session");
>                         session.setAttribute(key, sessTools);
>                     }
>                 }
>             }
>
>
> This creates the Toolbox instances for the current session and request
> and puts them where the ViewToolContext can find them.  Once all of
> the above is done, create your ViewToolContext and return that.
>
> i think that should do the trick.  sorry this is more complicated that
> i'd hoped.  i'll try and whip the VelocityView init code into
> something more forgiving and get a new beta out.  Thanks for bringing
> attention to this deficit. :)
>
> >  Thanks again.
> >
> >
> >
> >
> >  Charlie
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: user-unsubscribe@...
> >  For additional commands, e-mail: user-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Nathan Bubna]

On Tue, Apr 8, 2008 at 4:22 PM, Claude Brisson <claude@...> wrote:

>
>  Le mardi 08 avril 2008 à 15:15 -0700, Nathan Bubna a écrit :
>
> > On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
>  > > Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
>  > > so
>  > >  I can create a new VelocityView.  The best I can get is a ServletContext.
>  >
>  > That is a bummer.  Thank you!  Seriously, this exposes a signficant
>  > shortcoming in the plans to make it easy to integrate Tools into other
>  > frameworks.  It also made me realize that i didn't provide proper
>  > Filter support either.  It needs to be easier to init() a VelocityView
>  > (whether with a ServletConfig, FilterConfig or neither).  I'll try to
>  > set aside some time to fix that this week.  It'll mean we need to do
>  > another beta, i'm sure, but i think it'll be well worth it.
>
>  I noted this fact in http://issues.apache.org/jira/browse/VELTOOLS-94
>
>  :-)
>
>  It's some code you left apart for some reason...
>
>
>   Claude

sorry, i don't think i read that issue carefully the first time, or at
least i wasn't thinking straight.   because i apparently didn't think
through the fact that a filter can only get a FilterConfig, not a
ServletConfig.  i was in mexico at the time; guess i got a bit too
much sun on Christmas. ;)

anyway, i'll try to address some of these things this week.  and
please, feel free to help out.  and if you can't, at least keep close
tabs on me. obviously i haven't yet used this with a Filter, and it's
always easier to over/under engineer when doing something you don't
actually need at the moment.  extra eyes are appreciated.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Nathan Bubna]

Hey Charlie,

Any luck getting this to work yet?  Just curious...

thanks,
nathan

On Tue, Apr 8, 2008 at 3:15 PM, Nathan Bubna <nbubna@...> wrote:

> On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
>  > Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
>  > so
>  >  I can create a new VelocityView.  The best I can get is a ServletContext.
>
>  That is a bummer.  Thank you!  Seriously, this exposes a signficant
>  shortcoming in the plans to make it easy to integrate Tools into other
>  frameworks.  It also made me realize that i didn't provide proper
>  Filter support either.  It needs to be easier to init() a VelocityView
>  (whether with a ServletConfig, FilterConfig or neither).  I'll try to
>  set aside some time to fix that this week.  It'll mean we need to do
>  another beta, i'm sure, but i think it'll be well worth it.
>
>
>  >  ------------------------------------------------------------------
>  >  VelocityView velocityView = new VelocityView( getServletContext() );
>  >  Context context = velocityView.getContext( request, response );
>  >  ------------------------------------------------------------------
>  >
>  >  And, looking at the code for VelocityView, when you create a new
>  > VelocityView
>  >  with a ServletContext, it never calls the init(ServletConfig config)
>  > method.
>  >  So, the tools don't get configured.  When I do $params.get('thing') it
>  > tells me:
>  >
>  >   Request is null. ParameterTool must be initialized first!
>
>  Actually, this means the tools did get configured.  This just means
>  that the tool was never given access to the HttpServletRequest; the
>  tools aren't being properly initialized.
>
>  You could just precede $params.thing with $params.setRequest($request)
>  to make this work, but obviously that shouldn't be necessary and would
>  not work for tools who use configure() instead of setters.
>
>
>  >  So, I tried it the "standalone" way:
>  >  ------------------------------------------------------------------
>  >  ToolManager manager = new ToolManager();
>  >  if( getToolboxConfigLocation() != null )
>  >  {
>  >    manager.configure( getServletContext().getRealPath(
>  > getToolboxConfigLocation() ) );
>  >  }
>  >  manager.setVelocityEngine( getVelocityEngine() );
>  >  Context context = manager.createContext();
>  >  ------------------------------------------------------------------
>  >
>  >  And I get the same result.
>
>  As expected.  The code above has no knowledge of ServletRequests, so
>  it would be unable to tell tools about them.
>
>
>  >  One other attempt was made:
>  >  ------------------------------------------------------------------
>  >  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
>  >                                               request, response,
>  > getServletContext() );
>  >  ------------------------------------------------------------------
>  >
>  >  This time, no errors.  But the tools don't work.  I see a bunch of
>  > $link.setRelative()
>  >  all over the page.  Nothing renders.
>
>  That's because the ViewToolContext only knows how to find tools.  It
>  doesn't create them at all.
>
>
>  >
>  >  Am I close?  Way off?  Any help is much appreciated.
>  >
>
>  Your last example is actually headed in the right direction.
>  Unfortunately, since you can't use VelocityView until i fix it, it's a
>  little more complicated.  Here's the gist, though i'll have to leave
>  you to fill in the blanks for the moment:
>
>  the first goal is to create a FactoryConfiguration, then configure a
>  new ToolboxFactory instance with that config.  this may look something
>  like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
>  for a much more involved example):
>
>  FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
>  read javadoc on this!
>  ToolboxFactory factory = new ToolboxFactory();
>  factory.configure(config);
>
>  keep this factory around for the life of the app.  you only want the
>  code above to happen once, not on every request!
>
>  this once-per-app initialization is also a good place to create your
>  application-scoped toolbox and put that in the servlet context.  that
>  code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
>  and looks roughly like this:
>
>         Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
>         if (appTools != null &&
>             servletContext.getAttribute(Toolbox.class.getName()) == null)
>         {
>             servletContext.setAttribute(Toolbox.class.getName(), appTools);
>         }
>
>
>  with that, the application level stuff should be ready to go; now we
>  just need to prep some things before every request.  so, before you
>  create that ViewToolContext in your last example above, use your
>  ToolboxFactory and do the following (this code is ripped from
>  VelocityView.prepareToolboxes()):
>
>         String key = Toolbox.class.getName();
>         if (factory.hasTools(Scope.REQUEST)
>             && request.getAttribute(key) == null)
>         {
>             // add request toolbox, if any
>             Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
>             if (reqTools != null)
>             {
>                 request.setAttribute(key, reqTools);
>             }
>         }
>
>         if (factory.hasTools("session"))
>         {
>              HttpSession session = request.getSession(true);
>               // allow only one thread at a time
>                synchronized(factory)
>                 {
>                     if (session.getAttribute(key) == null)
>                     {
>                         Toolbox sessTools =
>                             factory.createToolbox("session");
>                         session.setAttribute(key, sessTools);
>                     }
>                 }
>             }
>
>
>  This creates the Toolbox instances for the current session and request
>  and puts them where the ViewToolContext can find them.  Once all of
>  the above is done, create your ViewToolContext and return that.
>
>  i think that should do the trick.  sorry this is more complicated that
>  i'd hoped.  i'll try and whip the VelocityView init code into
>  something more forgiving and get a new beta out.  Thanks for bringing
>  attention to this deficit. :)
>
>
>
>  >  Thanks again.
>  >
>  >
>  >
>  >
>  >  Charlie
>  >
>  >
>  >  ---------------------------------------------------------------------
>  >  To unsubscribe, e-mail: user-unsubscribe@...
>  >  For additional commands, e-mail: user-help@...
>  >
>  >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Charles Harvey III]

You just reminded me.  I have been a bit busy lately but I have some time
now so I'll give it a shot.



Charlie


Nathan Bubna said the following on 4/17/2008 11:53 PM:

> Hey Charlie,
>
> Any luck getting this to work yet?  Just curious...
>
> thanks,
> nathan
>
> On Tue, Apr 8, 2008 at 3:15 PM, Nathan Bubna <nbubna@...> wrote:
>  
>> On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
>>  > Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
>>  > so
>>  >  I can create a new VelocityView.  The best I can get is a ServletContext.
>>
>>  That is a bummer.  Thank you!  Seriously, this exposes a signficant
>>  shortcoming in the plans to make it easy to integrate Tools into other
>>  frameworks.  It also made me realize that i didn't provide proper
>>  Filter support either.  It needs to be easier to init() a VelocityView
>>  (whether with a ServletConfig, FilterConfig or neither).  I'll try to
>>  set aside some time to fix that this week.  It'll mean we need to do
>>  another beta, i'm sure, but i think it'll be well worth it.
>>
>>
>>  >  ------------------------------------------------------------------
>>  >  VelocityView velocityView = new VelocityView( getServletContext() );
>>  >  Context context = velocityView.getContext( request, response );
>>  >  ------------------------------------------------------------------
>>  >
>>  >  And, looking at the code for VelocityView, when you create a new
>>  > VelocityView
>>  >  with a ServletContext, it never calls the init(ServletConfig config)
>>  > method.
>>  >  So, the tools don't get configured.  When I do $params.get('thing') it
>>  > tells me:
>>  >
>>  >   Request is null. ParameterTool must be initialized first!
>>
>>  Actually, this means the tools did get configured.  This just means
>>  that the tool was never given access to the HttpServletRequest; the
>>  tools aren't being properly initialized.
>>
>>  You could just precede $params.thing with $params.setRequest($request)
>>  to make this work, but obviously that shouldn't be necessary and would
>>  not work for tools who use configure() instead of setters.
>>
>>
>>  >  So, I tried it the "standalone" way:
>>  >  ------------------------------------------------------------------
>>  >  ToolManager manager = new ToolManager();
>>  >  if( getToolboxConfigLocation() != null )
>>  >  {
>>  >    manager.configure( getServletContext().getRealPath(
>>  > getToolboxConfigLocation() ) );
>>  >  }
>>  >  manager.setVelocityEngine( getVelocityEngine() );
>>  >  Context context = manager.createContext();
>>  >  ------------------------------------------------------------------
>>  >
>>  >  And I get the same result.
>>
>>  As expected.  The code above has no knowledge of ServletRequests, so
>>  it would be unable to tell tools about them.
>>
>>
>>  >  One other attempt was made:
>>  >  ------------------------------------------------------------------
>>  >  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
>>  >                                               request, response,
>>  > getServletContext() );
>>  >  ------------------------------------------------------------------
>>  >
>>  >  This time, no errors.  But the tools don't work.  I see a bunch of
>>  > $link.setRelative()
>>  >  all over the page.  Nothing renders.
>>
>>  That's because the ViewToolContext only knows how to find tools.  It
>>  doesn't create them at all.
>>
>>
>>  >
>>  >  Am I close?  Way off?  Any help is much appreciated.
>>  >
>>
>>  Your last example is actually headed in the right direction.
>>  Unfortunately, since you can't use VelocityView until i fix it, it's a
>>  little more complicated.  Here's the gist, though i'll have to leave
>>  you to fill in the blanks for the moment:
>>
>>  the first goal is to create a FactoryConfiguration, then configure a
>>  new ToolboxFactory instance with that config.  this may look something
>>  like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
>>  for a much more involved example):
>>
>>  FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
>>  read javadoc on this!
>>  ToolboxFactory factory = new ToolboxFactory();
>>  factory.configure(config);
>>
>>  keep this factory around for the life of the app.  you only want the
>>  code above to happen once, not on every request!
>>
>>  this once-per-app initialization is also a good place to create your
>>  application-scoped toolbox and put that in the servlet context.  that
>>  code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
>>  and looks roughly like this:
>>
>>         Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
>>         if (appTools != null &&
>>             servletContext.getAttribute(Toolbox.class.getName()) == null)
>>         {
>>             servletContext.setAttribute(Toolbox.class.getName(), appTools);
>>         }
>>
>>
>>  with that, the application level stuff should be ready to go; now we
>>  just need to prep some things before every request.  so, before you
>>  create that ViewToolContext in your last example above, use your
>>  ToolboxFactory and do the following (this code is ripped from
>>  VelocityView.prepareToolboxes()):
>>
>>         String key = Toolbox.class.getName();
>>         if (factory.hasTools(Scope.REQUEST)
>>             && request.getAttribute(key) == null)
>>         {
>>             // add request toolbox, if any
>>             Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
>>             if (reqTools != null)
>>             {
>>                 request.setAttribute(key, reqTools);
>>             }
>>         }
>>
>>         if (factory.hasTools("session"))
>>         {
>>              HttpSession session = request.getSession(true);
>>               // allow only one thread at a time
>>                synchronized(factory)
>>                 {
>>                     if (session.getAttribute(key) == null)
>>                     {
>>                         Toolbox sessTools =
>>                             factory.createToolbox("session");
>>                         session.setAttribute(key, sessTools);
>>                     }
>>                 }
>>             }
>>
>>
>>  This creates the Toolbox instances for the current session and request
>>  and puts them where the ViewToolContext can find them.  Once all of
>>  the above is done, create your ViewToolContext and return that.
>>
>>  i think that should do the trick.  sorry this is more complicated that
>>  i'd hoped.  i'll try and whip the VelocityView init code into
>>  something more forgiving and get a new beta out.  Thanks for bringing
>>  attention to this deficit. :)
>>
>>
>>
>>  >  Thanks again.
>>  >
>>  >
>>  >
>>  >
>>  >  Charlie
>>  >
>>  >
>>  >  ---------------------------------------------------------------------
>>  >  To unsubscribe, e-mail: user-unsubscribe@...
>>  >  For additional commands, e-mail: user-help@...
>>  >
>>  >
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
>  

[Charles Harvey III]

Nathan,
I of course never got around to doing any of this work.  But I checked
Subversion
and saw that you had been making lots of changes.

So I checked out the code last night and did a build of 2.0-SNAPSHOT,
dropped it
into my project and lo and behold, it worked!  No changes.  I had my own
tools
ready for tools-1.4 (which meant taking out the dependency) so
everything was
ready.

I went from
  spring-1.2.9.jar
  velocity-tools-1.4.jar

to
  spring-2.5.4.jar
  spring-web-2.5.4.jar
  spring-webmvc-2.5.4.jar  (the Spring people broke out more code in the
new version)
  velocity-tools-2.0-SNAPSHOT.jar

And everything is great.  Great stuff.  Thanks so much for taking the
time to work
on all of this.


Charlie



Nathan Bubna said the following on 4/17/2008 11:53 PM:

> Hey Charlie,
>
> Any luck getting this to work yet?  Just curious...
>
> thanks,
> nathan
>
> On Tue, Apr 8, 2008 at 3:15 PM, Nathan Bubna <nbubna@...> wrote:
>  
>> On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...> wrote:
>>  > Ok.  I tried and tried and I cannot get the ServletConfig to where I need it
>>  > so
>>  >  I can create a new VelocityView.  The best I can get is a ServletContext.
>>
>>  That is a bummer.  Thank you!  Seriously, this exposes a signficant
>>  shortcoming in the plans to make it easy to integrate Tools into other
>>  frameworks.  It also made me realize that i didn't provide proper
>>  Filter support either.  It needs to be easier to init() a VelocityView
>>  (whether with a ServletConfig, FilterConfig or neither).  I'll try to
>>  set aside some time to fix that this week.  It'll mean we need to do
>>  another beta, i'm sure, but i think it'll be well worth it.
>>
>>
>>  >  ------------------------------------------------------------------
>>  >  VelocityView velocityView = new VelocityView( getServletContext() );
>>  >  Context context = velocityView.getContext( request, response );
>>  >  ------------------------------------------------------------------
>>  >
>>  >  And, looking at the code for VelocityView, when you create a new
>>  > VelocityView
>>  >  with a ServletContext, it never calls the init(ServletConfig config)
>>  > method.
>>  >  So, the tools don't get configured.  When I do $params.get('thing') it
>>  > tells me:
>>  >
>>  >   Request is null. ParameterTool must be initialized first!
>>
>>  Actually, this means the tools did get configured.  This just means
>>  that the tool was never given access to the HttpServletRequest; the
>>  tools aren't being properly initialized.
>>
>>  You could just precede $params.thing with $params.setRequest($request)
>>  to make this work, but obviously that shouldn't be necessary and would
>>  not work for tools who use configure() instead of setters.
>>
>>
>>  >  So, I tried it the "standalone" way:
>>  >  ------------------------------------------------------------------
>>  >  ToolManager manager = new ToolManager();
>>  >  if( getToolboxConfigLocation() != null )
>>  >  {
>>  >    manager.configure( getServletContext().getRealPath(
>>  > getToolboxConfigLocation() ) );
>>  >  }
>>  >  manager.setVelocityEngine( getVelocityEngine() );
>>  >  Context context = manager.createContext();
>>  >  ------------------------------------------------------------------
>>  >
>>  >  And I get the same result.
>>
>>  As expected.  The code above has no knowledge of ServletRequests, so
>>  it would be unable to tell tools about them.
>>
>>
>>  >  One other attempt was made:
>>  >  ------------------------------------------------------------------
>>  >  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
>>  >                                               request, response,
>>  > getServletContext() );
>>  >  ------------------------------------------------------------------
>>  >
>>  >  This time, no errors.  But the tools don't work.  I see a bunch of
>>  > $link.setRelative()
>>  >  all over the page.  Nothing renders.
>>
>>  That's because the ViewToolContext only knows how to find tools.  It
>>  doesn't create them at all.
>>
>>
>>  >
>>  >  Am I close?  Way off?  Any help is much appreciated.
>>  >
>>
>>  Your last example is actually headed in the right direction.
>>  Unfortunately, since you can't use VelocityView until i fix it, it's a
>>  little more complicated.  Here's the gist, though i'll have to leave
>>  you to fill in the blanks for the moment:
>>
>>  the first goal is to create a FactoryConfiguration, then configure a
>>  new ToolboxFactory instance with that config.  this may look something
>>  like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
>>  for a much more involved example):
>>
>>  FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
>>  read javadoc on this!
>>  ToolboxFactory factory = new ToolboxFactory();
>>  factory.configure(config);
>>
>>  keep this factory around for the life of the app.  you only want the
>>  code above to happen once, not on every request!
>>
>>  this once-per-app initialization is also a good place to create your
>>  application-scoped toolbox and put that in the servlet context.  that
>>  code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
>>  and looks roughly like this:
>>
>>         Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
>>         if (appTools != null &&
>>             servletContext.getAttribute(Toolbox.class.getName()) == null)
>>         {
>>             servletContext.setAttribute(Toolbox.class.getName(), appTools);
>>         }
>>
>>
>>  with that, the application level stuff should be ready to go; now we
>>  just need to prep some things before every request.  so, before you
>>  create that ViewToolContext in your last example above, use your
>>  ToolboxFactory and do the following (this code is ripped from
>>  VelocityView.prepareToolboxes()):
>>
>>         String key = Toolbox.class.getName();
>>         if (factory.hasTools(Scope.REQUEST)
>>             && request.getAttribute(key) == null)
>>         {
>>             // add request toolbox, if any
>>             Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
>>             if (reqTools != null)
>>             {
>>                 request.setAttribute(key, reqTools);
>>             }
>>         }
>>
>>         if (factory.hasTools("session"))
>>         {
>>              HttpSession session = request.getSession(true);
>>               // allow only one thread at a time
>>                synchronized(factory)
>>                 {
>>                     if (session.getAttribute(key) == null)
>>                     {
>>                         Toolbox sessTools =
>>                             factory.createToolbox("session");
>>                         session.setAttribute(key, sessTools);
>>                     }
>>                 }
>>             }
>>
>>
>>  This creates the Toolbox instances for the current session and request
>>  and puts them where the ViewToolContext can find them.  Once all of
>>  the above is done, create your ViewToolContext and return that.
>>
>>  i think that should do the trick.  sorry this is more complicated that
>>  i'd hoped.  i'll try and whip the VelocityView init code into
>>  something more forgiving and get a new beta out.  Thanks for bringing
>>  attention to this deficit. :)
>>
>>
>>
>>  >  Thanks again.
>>  >
>>  >
>>  >
>>  >
>>  >  Charlie
>>  >
>>  >
>>  >  ---------------------------------------------------------------------
>>  >  To unsubscribe, e-mail: user-unsubscribe@...
>>  >  For additional commands, e-mail: user-help@...
>>  >
>>  >
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Nathan Bubna]

That's great news!  Thanks for the update.  Hopefully i'll get my act
together and push out 2.0-beta2 in the next week.  No promises, of
course. :)

On Tue, May 13, 2008 at 2:34 PM, Charles Harvey III <charlieh@...> wrote:

> Nathan,
>  I of course never got around to doing any of this work.  But I checked
> Subversion
>  and saw that you had been making lots of changes.
>
>  So I checked out the code last night and did a build of 2.0-SNAPSHOT,
> dropped it
>  into my project and lo and behold, it worked!  No changes.  I had my own
> tools
>  ready for tools-1.4 (which meant taking out the dependency) so everything
> was
>  ready.
>
>  I went from
>   spring-1.2.9.jar
>   velocity-tools-1.4.jar
>
>  to
>   spring-2.5.4.jar
>   spring-web-2.5.4.jar
>   spring-webmvc-2.5.4.jar  (the Spring people broke out more code in the new
> version)
>   velocity-tools-2.0-SNAPSHOT.jar
>
>  And everything is great.  Great stuff.  Thanks so much for taking the time
> to work
>  on all of this.
>
>
>
>  Charlie
>
>
>
>  Nathan Bubna said the following on 4/17/2008 11:53 PM:
>
>
> > Hey Charlie,
> >
> > Any luck getting this to work yet?  Just curious...
> >
> > thanks,
> > nathan
> >
> > On Tue, Apr 8, 2008 at 3:15 PM, Nathan Bubna <nbubna@...> wrote:
> >
> >
> > > On Tue, Apr 8, 2008 at 2:10 PM, Charles Harvey III <charlieh@...>
> wrote:
> > >  > Ok.  I tried and tried and I cannot get the ServletConfig to where I
> need it
> > >  > so
> > >  >  I can create a new VelocityView.  The best I can get is a
> ServletContext.
> > >
> > >  That is a bummer.  Thank you!  Seriously, this exposes a signficant
> > >  shortcoming in the plans to make it easy to integrate Tools into other
> > >  frameworks.  It also made me realize that i didn't provide proper
> > >  Filter support either.  It needs to be easier to init() a VelocityView
> > >  (whether with a ServletConfig, FilterConfig or neither).  I'll try to
> > >  set aside some time to fix that this week.  It'll mean we need to do
> > >  another beta, i'm sure, but i think it'll be well worth it.
> > >
> > >
> > >  >  ------------------------------------------------------------------
> > >  >  VelocityView velocityView = new VelocityView( getServletContext() );
> > >  >  Context context = velocityView.getContext( request, response );
> > >  >  ------------------------------------------------------------------
> > >  >
> > >  >  And, looking at the code for VelocityView, when you create a new
> > >  > VelocityView
> > >  >  with a ServletContext, it never calls the init(ServletConfig config)
> > >  > method.
> > >  >  So, the tools don't get configured.  When I do $params.get('thing')
> it
> > >  > tells me:
> > >  >
> > >  >   Request is null. ParameterTool must be initialized first!
> > >
> > >  Actually, this means the tools did get configured.  This just means
> > >  that the tool was never given access to the HttpServletRequest; the
> > >  tools aren't being properly initialized.
> > >
> > >  You could just precede $params.thing with $params.setRequest($request)
> > >  to make this work, but obviously that shouldn't be necessary and would
> > >  not work for tools who use configure() instead of setters.
> > >
> > >
> > >  >  So, I tried it the "standalone" way:
> > >  >  ------------------------------------------------------------------
> > >  >  ToolManager manager = new ToolManager();
> > >  >  if( getToolboxConfigLocation() != null )
> > >  >  {
> > >  >    manager.configure( getServletContext().getRealPath(
> > >  > getToolboxConfigLocation() ) );
> > >  >  }
> > >  >  manager.setVelocityEngine( getVelocityEngine() );
> > >  >  Context context = manager.createContext();
> > >  >  ------------------------------------------------------------------
> > >  >
> > >  >  And I get the same result.
> > >
> > >  As expected.  The code above has no knowledge of ServletRequests, so
> > >  it would be unable to tell tools about them.
> > >
> > >
> > >  >  One other attempt was made:
> > >  >  ------------------------------------------------------------------
> > >  >  ViewToolContext context = new ViewToolContext( getVelocityEngine(),
> > >  >                                               request, response,
> > >  > getServletContext() );
> > >  >  ------------------------------------------------------------------
> > >  >
> > >  >  This time, no errors.  But the tools don't work.  I see a bunch of
> > >  > $link.setRelative()
> > >  >  all over the page.  Nothing renders.
> > >
> > >  That's because the ViewToolContext only knows how to find tools.  It
> > >  doesn't create them at all.
> > >
> > >
> > >  >
> > >  >  Am I close?  Way off?  Any help is much appreciated.
> > >  >
> > >
> > >  Your last example is actually headed in the right direction.
> > >  Unfortunately, since you can't use VelocityView until i fix it, it's a
> > >  little more complicated.  Here's the gist, though i'll have to leave
> > >  you to fill in the blanks for the moment:
> > >
> > >  the first goal is to create a FactoryConfiguration, then configure a
> > >  new ToolboxFactory instance with that config.  this may look something
> > >  like this (see VelocityView.configure(ServletConfig, ToolboxFactory)
> > >  for a much more involved example):
> > >
> > >  FactoryConfiguration config = ConfigurationUtils.getAutoLoaded(); //
> > >  read javadoc on this!
> > >  ToolboxFactory factory = new ToolboxFactory();
> > >  factory.configure(config);
> > >
> > >  keep this factory around for the life of the app.  you only want the
> > >  code above to happen once, not on every request!
> > >
> > >  this once-per-app initialization is also a good place to create your
> > >  application-scoped toolbox and put that in the servlet context.  that
> > >  code is ripped from VelocityView.init(ServletConfig,ToolboxFactory)
> > >  and looks roughly like this:
> > >
> > >        Toolbox appTools = factory.createToolbox(Scope.APPLICATION);
> > >        if (appTools != null &&
> > >            servletContext.getAttribute(Toolbox.class.getName()) == null)
> > >        {
> > >            servletContext.setAttribute(Toolbox.class.getName(),
> appTools);
> > >        }
> > >
> > >
> > >  with that, the application level stuff should be ready to go; now we
> > >  just need to prep some things before every request.  so, before you
> > >  create that ViewToolContext in your last example above, use your
> > >  ToolboxFactory and do the following (this code is ripped from
> > >  VelocityView.prepareToolboxes()):
> > >
> > >        String key = Toolbox.class.getName();
> > >        if (factory.hasTools(Scope.REQUEST)
> > >            && request.getAttribute(key) == null)
> > >        {
> > >            // add request toolbox, if any
> > >            Toolbox reqTools = factory.createToolbox(Scope.REQUEST);
> > >            if (reqTools != null)
> > >            {
> > >                request.setAttribute(key, reqTools);
> > >            }
> > >        }
> > >
> > >        if (factory.hasTools("session"))
> > >        {
> > >             HttpSession session = request.getSession(true);
> > >              // allow only one thread at a time
> > >               synchronized(factory)
> > >                {
> > >                    if (session.getAttribute(key) == null)
> > >                    {
> > >                        Toolbox sessTools =
> > >                            factory.createToolbox("session");
> > >                        session.setAttribute(key, sessTools);
> > >                    }
> > >                }
> > >            }
> > >
> > >
> > >  This creates the Toolbox instances for the current session and request
> > >  and puts them where the ViewToolContext can find them.  Once all of
> > >  the above is done, create your ViewToolContext and return that.
> > >
> > >  i think that should do the trick.  sorry this is more complicated that
> > >  i'd hoped.  i'll try and whip the VelocityView init code into
> > >  something more forgiving and get a new beta out.  Thanks for bringing
> > >  attention to this deficit. :)
> > >
> > >
> > >
> > >  >  Thanks again.
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >  Charlie
> > >  >
> > >  >
> > >  >
> ---------------------------------------------------------------------
> > >  >  To unsubscribe, e-mail: user-unsubscribe@...
> > >  >  For additional commands, e-mail: user-help@...
> > >  >
> > >  >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@...
> > For additional commands, e-mail: user-help@...
> >
> >
> >
> >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: user-unsubscribe@...
>  For additional commands, e-mail: user-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...