You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Russell Edens <ru...@speakeasy.net> on 2001/03/16 11:57:33 UTC
latest CVS failed to initialize TurbineVelocityService
i tried to build and run the lastest and greatest and i ran into the following
exception :
[Fri Mar 16 02:35:58 PST 2001] -- ERROR -- Service TurbineVelocityService
failed to initialize
Exception: org.apache.turbine.services.InstantiationException: Service
TurbineVelocityService failed to initialize
Stack Trace follows:
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:380)
at
org.apache.turbine.services.velocity.TurbineVelocityService.initVelocity(Turbine
VelocityService.java:380)
(full trace removed)
i walked into the code and it looks like a the calls:
String vProperties = TurbineServlet.getRealPath(
props.getProperty("properties", null));
String vLog = TurbineServlet.getRealPath(
props.getProperty("log", null));
String vTemplates = TurbineServlet.getRealPath(
props.getProperty("templates", null));
are returning null. has the structure of these setting changed in the
TR.properties? anybody have any clue?
(the worst part is that i had just upgraded all our code to work with a build
from the March 6th and at the last minute i got brave and decided that i would
go for the very latest. a very groggy - lol.)
thanks,
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: latest CVS failed to initialize TurbineVelocityService
Posted by John McNally <jm...@collab.net>.
I just started getting a npe in the TurbineVelocityService as well. I
have discovered that TurbineServletService.init(ServletConfig) is not
being called, so servletContext is not being set and therefore the calls
to getRealPath are failing.
John McNally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Russell Edens <ru...@speakeasy.net>.
Thanks, but my TR.propertis entry is exactly
services.TurbineVelocityService.properties=/WEB-INF/conf/velocity.properties
The problem was:
The order of service entries in the TR.properties is really fragile.
Because I have changed the order proper initialization of TurbineServletService
stopped working.
This is due to two factors. The first factor is that the order of the items
in the TR.props is not honored. (They are loaded into a map and then
enumerated.)
The second factor is tight coupling between services. (TurbineTemplateService
uses
TurbineServletService during its initialization, but TurbineServletService has
not been
initialized so it trys to initialize it. That all sounds fine and good, the
problem is that
the initializer it uses does not pass in a ServletConfig. So now
TurbineServletService is
initialized but missing has a null servletConfig member variable. Meanwhile the
TurbineTemplateService
attempts to use the TurbineServletService to try to get path information via
getRealPath, but whoa that
wont work because getRealPath uses ServletConfig!!! (If you understood that
then more power 2 u!)
My workaround:
Reorder my items to match the checked in TR.properties exactly. (Lame and Lucky
but it works.)
Jason just posted a thread titled 'Service Initialization and Order' on this.
(Just about 6 hours too late for me.<g>)
Russell
> -----Original Message-----
> From: Ilkka Priha [mailto:ext-ilkka.priha@nokia.com]
> Sent: Friday, March 16, 2001 4:57 AM
> To: turbine-user@jakarta.apache.org
> Subject: RE: latest CVS failed to initialize TurbineVelocityService
>
>
> I can reproduce this error, when the property specifying the path to the
> velocity.properties file is incorrect or the velocity.properties file
> is missing
> (actually the same thing). The default setting in TR is
>
> services.TurbineVelocityService.properties=/WEB-INF/conf/velocity.properties
>
> When this setting is correct, I haven't had any problems running today's build
> with Velocity.
>
> -- Ilkka
>
> [mailto:ext-ilkka.priha@nokia.com]
>
>
> -----Original Message-----
> From: Russell Edens [mailto:russell@speakeasy.net]
> Sent: 16. maaliskuuta 2001 12:58
> To: Turbine-Users
> Subject: latest CVS failed to initialize TurbineVelocityService
>
>
> i tried to build and run the lastest and greatest and i ran into the following
> exception :
>
> [Fri Mar 16 02:35:58 PST 2001] -- ERROR -- Service
> TurbineVelocityService
> failed to initialize
> Exception: org.apache.turbine.services.InstantiationException: Service
> TurbineVelocityService failed to initialize
> Stack Trace follows:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:380)
> at
> org.apache.turbine.services.velocity.TurbineVelocityService.initVeloci
> ty(Turbine
> VelocityService.java:380)
>
> (full trace removed)
>
> i walked into the code and it looks like a the calls:
>
> String vProperties = TurbineServlet.getRealPath(
> props.getProperty("properties", null));
>
> String vLog = TurbineServlet.getRealPath(
> props.getProperty("log", null));
>
> String vTemplates = TurbineServlet.getRealPath(
> props.getProperty("templates", null));
>
> are returning null. has the structure of these setting changed in the
> TR.properties? anybody have any clue?
>
> (the worst part is that i had just upgraded all our code to work with a build
> from the March 6th and at the last minute i got brave and decided that i would
> go for the very latest. a very groggy - lol.)
>
> thanks,
> russell
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Ilkka Priha <ex...@nokia.com>.
I can reproduce this error, when the property specifying the path to the
velocity.properties file is incorrect or the velocity.properties file is missing
(actually the same thing). The default setting in TR is
services.TurbineVelocityService.properties=/WEB-INF/conf/velocity.properties
When this setting is correct, I haven't had any problems running today's build
with Velocity.
-- Ilkka
[mailto:ext-ilkka.priha@nokia.com]
-----Original Message-----
From: Russell Edens [mailto:russell@speakeasy.net]
Sent: 16. maaliskuuta 2001 12:58
To: Turbine-Users
Subject: latest CVS failed to initialize TurbineVelocityService
i tried to build and run the lastest and greatest and i ran into the following
exception :
[Fri Mar 16 02:35:58 PST 2001] -- ERROR -- Service TurbineVelocityService
failed to initialize
Exception: org.apache.turbine.services.InstantiationException: Service
TurbineVelocityService failed to initialize
Stack Trace follows:
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:380)
at
org.apache.turbine.services.velocity.TurbineVelocityService.initVelocity(Turbine
VelocityService.java:380)
(full trace removed)
i walked into the code and it looks like a the calls:
String vProperties = TurbineServlet.getRealPath(
props.getProperty("properties", null));
String vLog = TurbineServlet.getRealPath(
props.getProperty("log", null));
String vTemplates = TurbineServlet.getRealPath(
props.getProperty("templates", null));
are returning null. has the structure of these setting changed in the
TR.properties? anybody have any clue?
(the worst part is that i had just upgraded all our code to work with a build
from the March 6th and at the last minute i got brave and decided that i would
go for the very latest. a very groggy - lol.)
thanks,
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: latest CVS failed to initialize TurbineVelocityService
Posted by Jason van Zyl <jv...@apache.org>.
Russell Edens wrote:
>
> Jason van Zyl wrote:
> > They are in the ServletService intentionally. You can use RunData
> > when you have access to it, but in things like scheduled job classes
> > you have no access to a RunData object. Anywhere that you don't
> > have access to RunData but need information about the servlet
> > environment the Servlet service is what you can use.
> >
> > > (They don't work reliably right now anyway.)
> >
> > What do you mean they don't work reliably?
> >
> > How will they shoot themselves in the foot? I've been using the
> > ServletService for over a month now and it works great.
>
> The code bellow reproduces the initialization problem I ran into.
>
> public class TestServletService extends Screen
> {
> public ConcreteElement doBuild(RunData data) throws Exception
> {
> StringBuffer sbOutput = new StringBuffer();
>
> sbOutput.append("getServerScheme: ")
> .append(TurbineServlet.getServerScheme())
> .append("\n")
>
> .append("getServerName: ")
> .append(TurbineServlet.getServerName())
> .append("\n")
>
> .append("getServerPort: ")
> .append(TurbineServlet.getServerPort())
> .append("\n")
>
> .append("getContextPath: ")
> .append(TurbineServlet.getContextPath())
> .append("\n");
>
> return new PRE(sbOutput.toString());
> }
> }
>
I'll take a look at that. You should definitely not get an error
in a screen like that. I use the TurbineServlet service in a lot of
classes
and don't have this problem. I'm going to add an example of how
to use the TurbineServletService in the TDK so I will test it.
> The other problem I see is if you initialize the ServletService via late
> initalization with a request comming in on HTTP. Then another request comes in
> on HTTPS, the call TurbineServlet.getServerScheme() will return HTTP not HTTPS.
> Correct?
Yes, you would probably run into this in a mixed http/https webapp.
But this could be overcome possibly with the use of the use.ssl property
in TR.props, or some file that describes your site as to which portions
of it are secure. Again, this class is intended to allow classes which
don't have access to RunData, and to allow the removal of init(RunData)
from the services as all that does is initialize with the first RunData
object produced and the ServletService has all the info from the first
RunData service. If you want to use RunData feel free.
I will look into the error you are getting. That shouldn't be
happening. I will test.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Russell Edens <ru...@speakeasy.net>.
Jason van Zyl wrote:
> They are in the ServletService intentionally. You can use RunData
> when you have access to it, but in things like scheduled job classes
> you have no access to a RunData object. Anywhere that you don't
> have access to RunData but need information about the servlet
> environment the Servlet service is what you can use.
>
> > (They don't work reliably right now anyway.)
>
> What do you mean they don't work reliably?
>
> How will they shoot themselves in the foot? I've been using the
> ServletService for over a month now and it works great.
The code bellow reproduces the initialization problem I ran into.
public class TestServletService extends Screen
{
public ConcreteElement doBuild(RunData data) throws Exception
{
StringBuffer sbOutput = new StringBuffer();
sbOutput.append("getServerScheme: ")
.append(TurbineServlet.getServerScheme())
.append("\n")
.append("getServerName: ")
.append(TurbineServlet.getServerName())
.append("\n")
.append("getServerPort: ")
.append(TurbineServlet.getServerPort())
.append("\n")
.append("getContextPath: ")
.append(TurbineServlet.getContextPath())
.append("\n");
return new PRE(sbOutput.toString());
}
}
The other problem I see is if you initialize the ServletService via late
initalization with a request comming in on HTTP. Then another request comes in
on HTTPS, the call TurbineServlet.getServerScheme() will return HTTP not HTTPS.
Correct?
> > (The only class in Turbine that
> > calls them is the UIManager
>
> Not true, I use them in scheduled job classes, and even within
> Turbine I want to replace all the service init(RunData) methods
> to init() and use the ServletService to get the required info
> about the servlet environment.
FYI - I locally removed the forementioned methods from the ServletService and
UIManager and successfully re-built all of Turbine.
> > and it even has an alternate method that passed
> > RunData with a comment that points out the potential for this bug.)
>
> You could do that, but I think it's inappropriate in templates. A
> designer shouldn't have to know about $data. For example:
I could not agree with you more on this point.
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: latest CVS failed to initialize TurbineVelocityService
Posted by Jason van Zyl <jv...@apache.org>.
Russell Edens wrote:
>
> Jason van Zyl wrote:
> > Sure, you can send me your fix, the initialization order coupled
> > with some changes will make the problem go away. Almost all of
> > the services will only require late initialization because any
> > servlet/rundata info can be retrieved from the servlet service.
> > The servlet service should be 'alive' before any of the other
> > standard services are initialized. There are a couple of services
> > that are still initializing with ServletConfig and/or RunData but
> > these init() methods can go away and the services that require
> > information about the servlet should get it from the servlet
> > service.
> >
> > I think this will take care of it, do you still see a problem
> > after this fix is made?
>
> I got your latest and the order dependency is fixed. Thanks! The problem I was
> having occured becuase I was using the methods:
> public String getServerScheme();
> public String getServerName();
> public String getServerPort();
> public String getContextPath();
> on the ServletService. IMO these are request level methods and should not be
> exposed on the ServletService.
They are in the ServletService intentionally. You can use RunData
when you have access to it, but in things like scheduled job classes
you have no access to a RunData object. Anywhere that you don't
have access to RunData but need information about the servlet
environment the Servlet service is what you can use.
> (They don't work reliably right now anyway.)
What do you mean they don't work reliably?
> You can get at the same methods on the RunData object. (Being new to Turbine I
> just overlooked this rather obvious fact.) Before someone else shoots
> themselves in the foot they should be removed.
How will they shoot themselves in the foot? I've been using the
ServletService for over a month now and it works great.
> (The only class in Turbine that
> calls them is the UIManager
Not true, I use them in scheduled job classes, and even within
Turbine I want to replace all the service init(RunData) methods
to init() and use the ServletService to get the required info
about the servlet environment.
> and it even has an alternate method that passed
> RunData with a comment that points out the potential for this bug.)
You could do that, but I think it's inappropriate in templates. A
designer shouldn't have to know about $data. For example:
$ui.image($image)
is better then
$ui.image($data, $image)
What does $data mean to a designer? I think the servlet info should
be implicit and not something the designer has to worry about. That's
one of the reasons the servlet service was made. Another is to provide
access to all the classes that need servlet info but don't have access
to RunData.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Russell Edens <ru...@speakeasy.net>.
Jason van Zyl wrote:
> Sure, you can send me your fix, the initialization order coupled
> with some changes will make the problem go away. Almost all of
> the services will only require late initialization because any
> servlet/rundata info can be retrieved from the servlet service.
> The servlet service should be 'alive' before any of the other
> standard services are initialized. There are a couple of services
> that are still initializing with ServletConfig and/or RunData but
> these init() methods can go away and the services that require
> information about the servlet should get it from the servlet
> service.
>
> I think this will take care of it, do you still see a problem
> after this fix is made?
I got your latest and the order dependency is fixed. Thanks! The problem I was
having occured becuase I was using the methods:
public String getServerScheme();
public String getServerName();
public String getServerPort();
public String getContextPath();
on the ServletService. IMO these are request level methods and should not be
exposed on the ServletService. (They don't work reliably right now anyway.)
You can get at the same methods on the RunData object. (Being new to Turbine I
just overlooked this rather obvious fact.) Before someone else shoots
themselves in the foot they should be removed. (The only class in Turbine that
calls them is the UIManager and it even has an alternate method that passed
RunData with a comment that points out the potential for this bug.)
So my fix is the easiest kind - remove the methods.
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: latest CVS failed to initialize TurbineVelocityService
Posted by Jason van Zyl <jv...@apache.org>.
Russell Edens wrote:
>
> Jason van Zyl wrote:
> > Everything to do with RunData was turned into a service
> > and it only contains an init() method, which in turbine
> > means late initialization as opposed to early initialization
> > with a ServletConfig.
> >
> > I suspect this is the problem but I'm not sure yet. The
> > servlet service initializes early in two phases, once
> > to grab the servlet config, and again to grab the RunData
> > object. Now that RunData is provided by a service and
> > is initializing after the servlet service we run into
> > a problem. I think the ordering of initialization of
> > the services against what appears in the TR.props
> > will fix this. I'll dig into it later this weekend
> > and let you know.
>
> I have a fix that ensures that TurbineServletService is not marked as inited
> until both early and late init occur. This should fix the problem regardless
> of the order of initialization. I'm pretty sure that this fix will be
> required even after the order of initializaiton is addressed, because
> TurbineServlet.getRealPath is called all over the place and that marks
> the service as initialized, but the service is not 'fully' initialized
> until both early and late init are called.
Sure, you can send me your fix, the initialization order coupled
with some changes will make the problem go away. Almost all of
the services will only require late initialization because any
servlet/rundata info can be retrieved from the servlet service.
The servlet service should be 'alive' before any of the other
standard services are initialized. There are a couple of services
that are still initializing with ServletConfig and/or RunData but
these init() methods can go away and the services that require
information about the servlet should get it from the servlet
service.
I think this will take care of it, do you still see a problem
after this fix is made?
>
> Jason - I do not have commit access, can I send this fix to you for commit?
>
> Let me know if you want any help working on the order of initialization -
> I've been digging around there lately and, although I'm still beefing up
> on the inner workings of Turbine, could make a good go at it.
I still plan to make a small proposal to the list today. In Velocity
I have combined the
ConfigurationsRepository/Configurations/ExtendedProperties
classes into a single Configuration class which I would like to
use in Turbine. I'm just writing a slew of unit tests for the
Configuration class then I'm going to try some things and then
post a proposal. I had to made some changes to the Configuration
class to make sure that when keys are retrieved that it is done
in the order they are set. This is either when read in a properties
file, or if a property is set dynamically.
I'll be working on it today. I will post something soon with
a more detailed explanation.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Russell Edens <ru...@speakeasy.net>.
Jason van Zyl wrote:
> Everything to do with RunData was turned into a service
> and it only contains an init() method, which in turbine
> means late initialization as opposed to early initialization
> with a ServletConfig.
>
> I suspect this is the problem but I'm not sure yet. The
> servlet service initializes early in two phases, once
> to grab the servlet config, and again to grab the RunData
> object. Now that RunData is provided by a service and
> is initializing after the servlet service we run into
> a problem. I think the ordering of initialization of
> the services against what appears in the TR.props
> will fix this. I'll dig into it later this weekend
> and let you know.
I have a fix that ensures that TurbineServletService is not marked as inited
until both early and late init occur. This should fix the problem regardless
of the order of initialization. I'm pretty sure that this fix will be
required even after the order of initializaiton is addressed, because
TurbineServlet.getRealPath is called all over the place and that marks
the service as initialized, but the service is not 'fully' initialized
until both early and late init are called.
Jason - I do not have commit access, can I send this fix to you for commit?
Let me know if you want any help working on the order of initialization -
I've been digging around there lately and, although I'm still beefing up
on the inner workings of Turbine, could make a good go at it.
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: latest CVS failed to initialize TurbineVelocityService
Posted by Jason van Zyl <jv...@apache.org>.
Russell Edens wrote:
>
> I ran into another related problem.
>
> I have some testing code that calls TurbineServlet.getServerScheme().
> It turns out that
> private String serverName = null;
> private String serverPort = null;
> private String serverScheme = null;
> private String contextPath = null;
> are no longer initialized.
> They get initialized in the
> public void init(RunData data)
> call - but that is not called anymore, the
> public void init( ServletConfig servletConfig )
> is called instead. Any thoughts on how to fix this?
>
Yes, I will fix this when I order the initialization of
the services to match the order that they are listed in
the TR.props.
Everything to do with RunData was turned into a service
and it only contains an init() method, which in turbine
means late initialization as opposed to early initialization
with a ServletConfig.
I suspect this is the problem but I'm not sure yet. The
servlet service initializes early in two phases, once
to grab the servlet config, and again to grab the RunData
object. Now that RunData is provided by a service and
is initializing after the servlet service we run into
a problem. I think the ordering of initialization of
the services against what appears in the TR.props
will fix this. I'll dig into it later this weekend
and let you know.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: latest CVS failed to initialize TurbineVelocityService
Posted by Russell Edens <ru...@speakeasy.net>.
I ran into another related problem.
I have some testing code that calls TurbineServlet.getServerScheme().
It turns out that
private String serverName = null;
private String serverPort = null;
private String serverScheme = null;
private String contextPath = null;
are no longer initialized.
They get initialized in the
public void init(RunData data)
call - but that is not called anymore, the
public void init( ServletConfig servletConfig )
is called instead. Any thoughts on how to fix this?
russell
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org