Jose Quinteiro escribió:
Hi,
As Jose, I would recommend having different instances for development
and deployment. Even though Resin does a good job on separating contexts
and detecting changes and restarting just the appropriate web app. You
will still affect your deployment applications with
On Feb 2, 2007, at 12:39 AM, Daniel López wrote:
> Jose Quinteiro escribió:
> Hi,
>
> As Jose, I would recommend having different instances for development
> and deployment. Even though Resin does a good job on separating
> contexts
> and detecting changes and restarting just the appropriate we
Use different taglib prefix in the included pages, that should do the
trick. -Kai
On 2/1/07, Murthy ch <[EMAIL PROTECTED]> wrote:
>
> I am new to resin websever.I am facing some problems when i try to use resin
> as webserver for a webapplication we developed.
>
> I am getting the following error
The rationale behind separate conf files is that the different
applications could potentially, but not necessarily, run on different
machines.
I found the key thing was that in order to have separate instances on
the same machine you must have different watchdog ports. E.g.
6706
Hi,
Interesting. One question though, if I edit the config file and modify one
of the cluster blocks, to add a new app for example, is Resin smart enough
to just restart that specific cluster or will it restart all the instances
due to the new timestamp of the config file? I guess it is the latter
I'm not sure I understood your question, but I'm going to answer anyway
(heh.)
What we do is have different web-app-deploy paths, like this:
"Host" can be a child of "cluster" so changing things in the app1
webapps directory should not affect any other cluster (or host?)
T
On Feb 2, 2007, at 11:27 AM, Daniel Lopez wrote:
> Hi,
>
> Interesting. One question though, if I edit the config file and
> modify one
> of the cluster blocks, to add a new app for example, is Resin smart
> enough
> to just restart that specific cluster or will it restart all the
> instanc
This problem has been baffling me for weeks now. We are running resin
(somewhat older 3.0.14 release) and I'm seeing something strange.
Much of our application's interface is implemented in JSP 2.0 *.tag files.
As part of our build process (using ant), we auto-generate a *.jsp file which
is
On Feb 2, 2007, at 3:21 PM, Gerry Panganiban wrote:
> This problem has been baffling me for weeks now. We are running
> resin (somewhat older 3.0.14 release) and I'm seeing something
> strange.
>
> Much of our application's interface is implemented in JSP 2.0
> *.tag files. As part of o
The dependency list looks correct. The tag files I am changing are listed
there.
Although I noticed that some of the values that are being passed into the
lastModified attribute are actually negative (e.g.: -6419312961657006312L)
--Gerry
--- [EMAIL PROTECTED] wrote:
From: Scott Ferguson <[EM
On Feb 2, 2007, at 4:37 PM, Gerry Panganiban wrote:
> The dependency list looks correct. The tag files I am changing are
> listed there.
> Although I noticed that some of the values that are being passed
> into the lastModified attribute are actually negative (e.g.:
> -6419312961657006312L)
Our tags are just jsp-tag files (*.tag), which I believe do not explictly
override the doStartTag() method (there is no such method in the compiled tag's
.java file)
--- [EMAIL PROTECTED] wrote:
From: Scott Ferguson <[EMAIL PROTECTED]>
To: General Discussion for the Resin application serv
I found what was interfering with the caching: it's sitemesh. I have
this filter-mapping:
sitemesh
*.jsp
If I remove that, it works fine. Once I found that, I realized that
adding the page pattern to the sitemesh exclude list solves the
problem. I don't understand wha
13 matches
Mail list logo
