You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/11/18 08:04:12 UTC
Loose end #1 -- tomcat configuration files
I now have servers for jetty and for tomcat built using the packaging
and assembly plugins. For the second time I've spent 2 days trying to
figure out why tomcat is broken only to realize that some required
configuration files are missing. The server built in modules/assembly
copies the files from the tomcat module, whereas I have simply included
them in the geronimo-tomcat-j2ee assembly. Both of these solutions are
really unsatisfactory.
How about writing a gbean that copies resources out of its classpath
and into a specified location (in var)? This would let us package
these files in the geronimo-tomcat car so they would be available for
any tomcat server. Can anyone see a problem with this approach?
thanks
david jencks
Re: Loose end #1 -- tomcat configuration files
Posted by Jeff Genender <jg...@apache.org>.
Many of the Tomcat components seem to need the concept of a "Catalina
Home". But this is not to say, that a majority of the components allow
for overrides to particular directory structures and locations. So
without looking at the code, I would probably say its doable...but this
is speculation.
Aaron Mulder wrote:
> I don't have any problems with your approach. But I also am not the
> biggest fan fo the var/catalina structure that Tomcat wants Geronimo
> to have. Is there some way to get Tomcat to use our directories
> directly (log, work, whatever) instead of doing everything under a
> Catalina directory?
>
> Aaron
>
> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>> I now have servers for jetty and for tomcat built using the packaging
>> and assembly plugins. For the second time I've spent 2 days trying to
>> figure out why tomcat is broken only to realize that some required
>> configuration files are missing. The server built in modules/assembly
>> copies the files from the tomcat module, whereas I have simply included
>> them in the geronimo-tomcat-j2ee assembly. Both of these solutions are
>> really unsatisfactory.
>>
>> How about writing a gbean that copies resources out of its classpath
>> and into a specified location (in var)? This would let us package
>> these files in the geronimo-tomcat car so they would be available for
>> any tomcat server. Can anyone see a problem with this approach?
>>
>> thanks
>> david jencks
>>
>>
Re: Loose end #1 -- tomcat configuration files
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I don't have any problems with your approach. But I also am not the
biggest fan fo the var/catalina structure that Tomcat wants Geronimo
to have. Is there some way to get Tomcat to use our directories
directly (log, work, whatever) instead of doing everything under a
Catalina directory?
Aaron
On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> I now have servers for jetty and for tomcat built using the packaging
> and assembly plugins. For the second time I've spent 2 days trying to
> figure out why tomcat is broken only to realize that some required
> configuration files are missing. The server built in modules/assembly
> copies the files from the tomcat module, whereas I have simply included
> them in the geronimo-tomcat-j2ee assembly. Both of these solutions are
> really unsatisfactory.
>
> How about writing a gbean that copies resources out of its classpath
> and into a specified location (in var)? This would let us package
> these files in the geronimo-tomcat car so they would be available for
> any tomcat server. Can anyone see a problem with this approach?
>
> thanks
> david jencks
>
>
Re: Loose end #1 -- tomcat configuration files
Posted by Joe Bohn <jo...@earthlink.net>.
I agree with this idea but I'd like to add one more thoughts. I think
that we need to make the sharing of the server configurations also
"configurable". A presumed sharing of binaries or configurations is not
always optimal (especially when upgrading from a v1 to a v2 server).
We also need to consider how this would influence the applications
installed on the various server instances in the same geronimo tree. I
think flexibility is the key here. Some users will want total isolation
of applications (even binaries) in the same Geronimo tree so that they
can manage the applications independently. Others may want to share all
of the application/configuration information across server instances.
And of course, there will be some that want a mixture of "island"
applications and "community" applications.
Joe
Matt Hogstrom wrote:
> I think anything we do in this area should start to factor in the idea
> of multiple configurations for a single Geronimo tree. For example, if
> I was running server 1 and server 2 and wanted to have unique containers
> for both I would need something like:
>
> $G/var/server1/catalina
>
> $G/var/server2/catalina
>
> as well as unique log4j properties files, config-store, etc. Continuing
> the single version per tree for 1.0 is fine but I'd like to see us start
> thinking in a larger context for more complicated customer deployments.
> In one instance a customer may server multiple servers from a single NAS.
>
> Just some food for thought.
>
> David Jencks wrote:
>
>> I now have servers for jetty and for tomcat built using the packaging
>> and assembly plugins. For the second time I've spent 2 days trying to
>> figure out why tomcat is broken only to realize that some required
>> configuration files are missing. The server built in modules/assembly
>> copies the files from the tomcat module, whereas I have simply
>> included them in the geronimo-tomcat-j2ee assembly. Both of these
>> solutions are really unsatisfactory.
>>
>> How about writing a gbean that copies resources out of its classpath
>> and into a specified location (in var)? This would let us package
>> these files in the geronimo-tomcat car so they would be available for
>> any tomcat server. Can anyone see a problem with this approach?
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot
Re: Loose end #1 -- tomcat configuration files
Posted by Dain Sundstrom <da...@iq80.com>.
Can you add a JIRA for 1.1?
-dain
On Nov 18, 2005, at 11:35 AM, Jeff Genender wrote:
> +100 on this idea...we need to support multiple instances. This is
> going to be key on hosting configuration and developer shared boxes.
>
> Matt Hogstrom wrote:
>> I think anything we do in this area should start to factor in the
>> idea of multiple configurations for a single Geronimo tree. For
>> example, if I was running server 1 and server 2 and wanted to have
>> unique containers for both I would need something like:
>> $G/var/server1/catalina
>> $G/var/server2/catalina
>> as well as unique log4j properties files, config-store, etc.
>> Continuing the single version per tree for 1.0 is fine but I'd
>> like to see us start thinking in a larger context for more
>> complicated customer deployments. In one instance a customer may
>> server multiple servers from a single NAS.
>> Just some food for thought.
>> David Jencks wrote:
>>> I now have servers for jetty and for tomcat built using the
>>> packaging and assembly plugins. For the second time I've spent 2
>>> days trying to figure out why tomcat is broken only to realize
>>> that some required configuration files are missing. The server
>>> built in modules/assembly copies the files from the tomcat
>>> module, whereas I have simply included them in the geronimo-
>>> tomcat-j2ee assembly. Both of these solutions are really
>>> unsatisfactory.
>>>
>>> How about writing a gbean that copies resources out of its
>>> classpath and into a specified location (in var)? This would let
>>> us package these files in the geronimo-tomcat car so they would
>>> be available for any tomcat server. Can anyone see a problem
>>> with this approach?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>
Re: Loose end #1 -- tomcat configuration files
Posted by John Sisson <jr...@gmail.com>.
JIRA issue "Review location of config-store directory" -
http://issues.apache.org/jira/browse/GERONIMO-739 should be considered
when looking at support for multiple instances.
John
Jeff Genender wrote:
> +100 on this idea...we need to support multiple instances. This is
> going to be key on hosting configuration and developer shared boxes.
>
> Matt Hogstrom wrote:
>
>> I think anything we do in this area should start to factor in the
>> idea of multiple configurations for a single Geronimo tree. For
>> example, if I was running server 1 and server 2 and wanted to have
>> unique containers for both I would need something like:
>>
>> $G/var/server1/catalina
>>
>> $G/var/server2/catalina
>>
>> as well as unique log4j properties files, config-store, etc.
>> Continuing the single version per tree for 1.0 is fine but I'd like
>> to see us start thinking in a larger context for more complicated
>> customer deployments. In one instance a customer may server multiple
>> servers from a single NAS.
>>
>> Just some food for thought.
>>
>> David Jencks wrote:
>>
>>> I now have servers for jetty and for tomcat built using the
>>> packaging and assembly plugins. For the second time I've spent 2
>>> days trying to figure out why tomcat is broken only to realize that
>>> some required configuration files are missing. The server built in
>>> modules/assembly copies the files from the tomcat module, whereas I
>>> have simply included them in the geronimo-tomcat-j2ee assembly.
>>> Both of these solutions are really unsatisfactory.
>>>
>>> How about writing a gbean that copies resources out of its classpath
>>> and into a specified location (in var)? This would let us package
>>> these files in the geronimo-tomcat car so they would be available
>>> for any tomcat server. Can anyone see a problem with this approach?
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>
>
Re: Loose end #1 -- tomcat configuration files
Posted by Jeff Genender <jg...@apache.org>.
+100 on this idea...we need to support multiple instances. This is
going to be key on hosting configuration and developer shared boxes.
Matt Hogstrom wrote:
> I think anything we do in this area should start to factor in the idea
> of multiple configurations for a single Geronimo tree. For example, if
> I was running server 1 and server 2 and wanted to have unique containers
> for both I would need something like:
>
> $G/var/server1/catalina
>
> $G/var/server2/catalina
>
> as well as unique log4j properties files, config-store, etc. Continuing
> the single version per tree for 1.0 is fine but I'd like to see us start
> thinking in a larger context for more complicated customer deployments.
> In one instance a customer may server multiple servers from a single NAS.
>
> Just some food for thought.
>
> David Jencks wrote:
>> I now have servers for jetty and for tomcat built using the packaging
>> and assembly plugins. For the second time I've spent 2 days trying to
>> figure out why tomcat is broken only to realize that some required
>> configuration files are missing. The server built in modules/assembly
>> copies the files from the tomcat module, whereas I have simply
>> included them in the geronimo-tomcat-j2ee assembly. Both of these
>> solutions are really unsatisfactory.
>>
>> How about writing a gbean that copies resources out of its classpath
>> and into a specified location (in var)? This would let us package
>> these files in the geronimo-tomcat car so they would be available for
>> any tomcat server. Can anyone see a problem with this approach?
>>
>> thanks
>> david jencks
>>
>>
>>
>>
Re: Loose end #1 -- tomcat configuration files
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I think anything we do in this area should start to factor in the idea of
multiple configurations for a single Geronimo tree. For example, if I was
running server 1 and server 2 and wanted to have unique containers for both I
would need something like:
$G/var/server1/catalina
$G/var/server2/catalina
as well as unique log4j properties files, config-store, etc. Continuing the
single version per tree for 1.0 is fine but I'd like to see us start thinking in
a larger context for more complicated customer deployments. In one instance a
customer may server multiple servers from a single NAS.
Just some food for thought.
David Jencks wrote:
> I now have servers for jetty and for tomcat built using the packaging
> and assembly plugins. For the second time I've spent 2 days trying to
> figure out why tomcat is broken only to realize that some required
> configuration files are missing. The server built in modules/assembly
> copies the files from the tomcat module, whereas I have simply included
> them in the geronimo-tomcat-j2ee assembly. Both of these solutions are
> really unsatisfactory.
>
> How about writing a gbean that copies resources out of its classpath and
> into a specified location (in var)? This would let us package these
> files in the geronimo-tomcat car so they would be available for any
> tomcat server. Can anyone see a problem with this approach?
>
> thanks
> david jencks
>
>
>
>
Re: Loose end #1 -- tomcat configuration files
Posted by Dain Sundstrom <da...@iq80.com>.
This is what I did in the GBuild report code. It has a nested zip
file containing all of the static content for the report, and when it
generates a report is simply unzips the file into the report
directory. You can just swipe the code from there.
-dain
On Nov 17, 2005, at 11:04 PM, David Jencks wrote:
> I now have servers for jetty and for tomcat built using the
> packaging and assembly plugins. For the second time I've spent 2
> days trying to figure out why tomcat is broken only to realize that
> some required configuration files are missing. The server built in
> modules/assembly copies the files from the tomcat module, whereas I
> have simply included them in the geronimo-tomcat-j2ee assembly.
> Both of these solutions are really unsatisfactory.
>
> How about writing a gbean that copies resources out of its
> classpath and into a specified location (in var)? This would let
> us package these files in the geronimo-tomcat car so they would be
> available for any tomcat server. Can anyone see a problem with
> this approach?
>
> thanks
> david jencks