dear antonio,
first of all, thx a lot for your answer. but i do not agree with your
explanations. for sure tiles relies on the fact that the configuration is
getting loaded during start up but in fact it is not realy getting loaded
until the first request has been received. even not using the default
servlet/listener/... that are part of the tiles release. the only thing that
is getting done - as far as i can see - is reading in the configuration but
not parsing it.
i took a look through the code and i did not see any synchronized work
inside it ragarding the initialization of the framework at start. in
generall the work done by the tiles configurere explained in the initial
email is more or less exactly the same as the work done by, e.g. the
TileListener, which is used by both, the TilesFilter and TilesServlet which
are explained to be use to initialize tiles at the tile documentation.
therefore, in my opinion it is not a failure in using/initializing tiles but
in tiles it self. this gets even more harden if you consider the fact that
the hole initialization work in my case is done within the servlet container
startup process, too. just like it is done by using the tiles default
implementation of its listener/servlet/filter.
if i got it right, creating the real beans/instances/what ever from the
configuration file(s) is not done before the first tile definition is
requested/told to render. therefore i think tiles should care about
synchronizing this work, not the application using tiles.
please correct me if i'm wrong.
greez,
dirk
----- Original Message -----
From: "Antonio Petrelli" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 27, 2007 10:10 AM
Subject: Re: tiles2 crashes (digester)
Hi Dirk,
Your example is really pretty complicated :-)
Seriously, Tiles relies on the fact that the configuration is read at
startup only once. This is done by using the listener, the filter or
the servlet.
For some strange reason, I think that your Spring integration does not
load on startup, so I guess it is a bug in Spring, or in your code.
What I mean is that Tiles is not responsible for a misuse of the
startup procedure.
For example, I think that the container creation and its assignment to
TilesAccess should be done in a synchronized block.
Ciao
Antonio
2007/8/19, Schaefer, Dirk Alexander <[EMAIL PROTECTED]>:
hi all,
i'm new to tiles2 and currently trying hard to get it working within my
spring enabled web application.
actually almost the hole thing is working proper with one exception.
tiles2 crashes while it reads the definitions from the definitionsFile(s)
i told it to read from within the following circumstances:
1. start the tomcat servlet container.
2. no request sent to tomcat since startup.
3. sending multiple request using a web application test application
simultaneously.
if i do this, a realy big number of exceptions occurre inside of tomcat.
investigating those exceptions i figured out, that there is a problem
when the definitions are getting read from the xml string held inside
tiles. as far as i can see, those definitions are then getting read using
digester. as i can see, reading the definitions is neither synchronized
nor is it using independent instances (thread bounded) of the class it is
using for this purpose.
the result is, that the different threads are messing with each other and
the process of loading the definitions crashs.
if i use it the following way, everything works proper:
1. start the tomcat servlet container.
2. send one single request to it at least.
3. send as many request simultanously as the server can handle.
interessting, isn't it?
---------------------------------------------------
how i use tiles2:
i do not use any of tiles' servlets, listeners, ... i initialize tiles
the programmatical way by using the spring framework's TilesConfigurer
introduced in its version 2.1 m4. in general it is first setting up
servlet initial parameters that are defining the several factory,
preparer, ... implementations to use by tiles.
after that it initializes the tiles framework the following way:
public void afterPropertiesSet() throws TilesException {
TilesContainer container = createTilesContainer(this.servletContext);
TilesAccess.setContainer(this.servletContext, container);
}
protected TilesContainer createTilesContainer(ServletContext context)
throws TilesException {
ServletContextAdapter adaptedContext = new ServletContextAdapter(new
DelegatingServletConfig());
TilesContainerFactory factory =
TilesContainerFactory.getFactory(adaptedContext);
return factory.createContainer(adaptedContext);
}
where afterPropertiesSet() is the method which needs to be invoked in
order to initialize tiles. DelegatingServletConfig is a simple inner
class of TilesConfigurer which makes the configurer's settings according
to the factory/preparer/... implementations to use by tiles available as
initial servlet property settings.
can anyone confirm that this is a bug within tiles2 or is it just me,
who's using tiles the wrong way?
thx a lot, greez,
dirk
