You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2005/10/11 20:27:25 UTC
More port conflicts
I have built M5 from the source. I am running the
default configuration (Jetty and Tomcat). I start The
following configurations :
org/apache/geronimo/applications/Welcome/Tomcat and
org/apache/geronimo/Console/Tomcat
Both theses configurations get started on port
8080. Even though Tomcat is running on port 8090:
Before I investigate further, is this a known
problem?
Thanks
Anita
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: More port conflicts
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- anita kulshreshtha <a_...@yahoo.com> wrote:
>
>
> --- David Jencks <da...@yahoo.com> wrote:
>
> >
> > On Oct 11, 2005, at 11:27 AM, anita kulshreshtha
> > wrote:
> >
> > > I have built M5 from the source. I am running
> > the
> > > default configuration (Jetty and Tomcat). I
> start
> > The
> > > following configurations :
> > > org/apache/geronimo/applications/Welcome/Tomcat
> > and
> > > org/apache/geronimo/Console/Tomcat
> > > Both theses configurations get started on
> port
> > > 8080. Even though Tomcat is running on port
> 8090:
> > > Before I investigate further, is this a
> known
> > > problem?
> >
> > How do you know what port they are on? if tomcat
> is
> > running on port
> > 8090 and jetty is running on 8080, then
> > org/apache/geronimo/Console/Tomcat is going to be
> > available on 8090 and
In Tomcat Console the statistics are not enabled.
This is the only way to tell the difference!
Thanks
Anita
> > org/apache/geronimo/Console/Jetty is going to be
> > available on 8080.
> >
> > I think there is a bug with what is reported when
> > the server starts,
> > all apps are reported as being on the first web
> > container no matter
> > which one they are running on.
>
> There is a bug which reports (probably in the
> deployer ?) which reports 'started on..' 8080. Even
> though the apps are started correctly. So here it is
> :
> 1. Server starts properly and the messages are
> correct.
> 2. The apps are being started correctly and are
> available on respective ports. Only the message is
> wrong. it would be nice if we could somehow convey
> this to newcomers.
> 3. Console with Tomcat still shows Jetty
> Connectors.
> This was a problem pre M5, may be the new changes
> have
> not made it to M5.
> >
> > thanks
> > david jencks
> >
> > >
> > > Thanks
> > > Anita
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > > http://mail.yahoo.com
> > >
> >
> >
>
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: More port conflicts
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- David Jencks <da...@yahoo.com> wrote:
>
> On Oct 11, 2005, at 11:27 AM, anita kulshreshtha
> wrote:
>
> > I have built M5 from the source. I am running
> the
> > default configuration (Jetty and Tomcat). I start
> The
> > following configurations :
> > org/apache/geronimo/applications/Welcome/Tomcat
> and
> > org/apache/geronimo/Console/Tomcat
> > Both theses configurations get started on port
> > 8080. Even though Tomcat is running on port 8090:
> > Before I investigate further, is this a known
> > problem?
>
> How do you know what port they are on? if tomcat is
> running on port
> 8090 and jetty is running on 8080, then
> org/apache/geronimo/Console/Tomcat is going to be
> available on 8090 and
> org/apache/geronimo/Console/Jetty is going to be
> available on 8080.
>
> I think there is a bug with what is reported when
> the server starts,
> all apps are reported as being on the first web
> container no matter
> which one they are running on.
There is a bug which reports (probably in the
deployer ?) which reports 'started on..' 8080. Even
though the apps are started correctly. So here it is :
1. Server starts properly and the messages are
correct.
2. The apps are being started correctly and are
available on respective ports. Only the message is
wrong. it would be nice if we could somehow convey
this to newcomers.
3. Console with Tomcat still shows Jetty Connectors.
This was a problem pre M5, may be the new changes have
not made it to M5.
>
> thanks
> david jencks
>
> >
> > Thanks
> > Anita
> >
> >
> >
> >
> > __________________________________
> > Yahoo! Mail - PC Magazine Editors' Choice 2005
> > http://mail.yahoo.com
> >
>
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Re: More port conflicts
Posted by David Jencks <da...@yahoo.com>.
On Oct 11, 2005, at 11:27 AM, anita kulshreshtha wrote:
> I have built M5 from the source. I am running the
> default configuration (Jetty and Tomcat). I start The
> following configurations :
> org/apache/geronimo/applications/Welcome/Tomcat and
> org/apache/geronimo/Console/Tomcat
> Both theses configurations get started on port
> 8080. Even though Tomcat is running on port 8090:
> Before I investigate further, is this a known
> problem?
How do you know what port they are on? if tomcat is running on port
8090 and jetty is running on 8080, then
org/apache/geronimo/Console/Tomcat is going to be available on 8090 and
org/apache/geronimo/Console/Jetty is going to be available on 8080.
I think there is a bug with what is reported when the server starts,
all apps are reported as being on the first web container no matter
which one they are running on.
thanks
david jencks
>
> Thanks
> Anita
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
Re: More port conflicts
Posted by Bruce Snyder <br...@gmail.com>.
On 10/11/05, anita kulshreshtha <a_...@yahoo.com> wrote:
> I have built M5 from the source. I am running the
> default configuration (Jetty and Tomcat). I start The
> following configurations :
> org/apache/geronimo/applications/Welcome/Tomcat and
> org/apache/geronimo/Console/Tomcat
> Both theses configurations get started on port
> 8080. Even though Tomcat is running on port 8090:
> Before I investigate further, is this a known
> problem?
I believe you need to get Tomcat running on port 8080 first. This can
be done by editing the etc/project.properties file and changing the
geronimo.web.container=tomcat or by running the maven goal whose name
is tomcat from within the assembly module.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: More port conflicts
Posted by Joe Bohn <jo...@earthlink.net>.
+1 I agree with the user perspective and think that a vote is a great idea.
toby cabot wrote:
>>The alternative to starting both web containers by default is to
>>start neither: we can't play favorites.
>
>
> Why can't we start only one web container by default? I understand
> that for political reasons it may be difficult to choose one over the
> other, so how about another poll like the logo contest? However the
> decision gets made, it needs to get made. Users who care can copy
> configuration files around, but users who don't have a preference for
> which web container to use shouldn't be forced to decide, they should
> just be able to start working with geronimo.
>
--
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: More port conflicts
Posted by toby cabot <to...@caboteria.org>.
> The alternative to starting both web containers by default is to
> start neither: we can't play favorites.
Why can't we start only one web container by default? I understand
that for political reasons it may be difficult to choose one over the
other, so how about another poll like the logo contest? However the
decision gets made, it needs to get made. Users who care can copy
configuration files around, but users who don't have a preference for
which web container to use shouldn't be forced to decide, they should
just be able to start working with geronimo.
Re: More port conflicts
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
>
> On Oct 12, 2005, at 11:48 AM, Dain Sundstrom wrote:
>
>>
>> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
>>
>>> 2) Have a separate binary image for both the Jetty and Tomcat
>>> webcontainers. I'm not suggesting biting off the whole task of
>>> revising the assembly process but rather just merely having two
>>> binaries each with a separate set of config files (config.xml,
>>> config.list). This could even be a post-build step done on the
>>> common image. This isn't very technically interesting but clearly
>>> communicates to users that there are two separate environments and
>>> they select the download that they want. Of course, this goes away
>>> if/when the assembly revision is complete.
>>
>>
>> +1 this is a reasonable compromise.
>>
>
> OK, one more idea for the list...
>
> I'm into testing on making config.xml serve as both the attribute store
> and the persistent configuration list. When this works, I think it
> would be useful to have a command line parameter that sets the
> location/name of the config.xml file to use (maybe a system property).
> Then we could choose the configuration on the command line
>
> java -jar bin/server.jar -Dgeronimo.configuration=geronimo-jetty.xml
>
> Scripts could remove the need to know the file name :-)
>
> ./geronimo-jetty
>
> Would this be adequate and remove the need for separate distributions?
Would this also solve the problem of there being invalid configurations
included in the runtime as I mentioned earlier (ex. the jetty/console
and jetty/welcome pre-deployed configurations being included in a tomcat
only configuration)?
>
> 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: More port conflicts
Posted by David Jencks <da...@yahoo.com>.
On Oct 12, 2005, at 11:48 AM, Dain Sundstrom wrote:
>
> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
>
>> 2) Have a separate binary image for both the Jetty and Tomcat
>> webcontainers. I'm not suggesting biting off the whole task of
>> revising the assembly process but rather just merely having two
>> binaries each with a separate set of config files (config.xml,
>> config.list). This could even be a post-build step done on the
>> common image. This isn't very technically interesting but clearly
>> communicates to users that there are two separate environments and
>> they select the download that they want. Of course, this goes away
>> if/when the assembly revision is complete.
>
> +1 this is a reasonable compromise.
>
OK, one more idea for the list...
I'm into testing on making config.xml serve as both the attribute
store and the persistent configuration list. When this works, I think
it would be useful to have a command line parameter that sets the
location/name of the config.xml file to use (maybe a system property).
Then we could choose the configuration on the command line
java -jar bin/server.jar -Dgeronimo.configuration=geronimo-jetty.xml
Scripts could remove the need to know the file name :-)
./geronimo-jetty
Would this be adequate and remove the need for separate distributions?
thanks
david jencks
Re: More port conflicts
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
> 2) Have a separate binary image for both the Jetty and Tomcat
> webcontainers. I'm not suggesting biting off the whole task of
> revising the assembly process but rather just merely having two
> binaries each with a separate set of config files (config.xml,
> config.list). This could even be a post-build step done on the
> common image. This isn't very technically interesting but clearly
> communicates to users that there are two separate environments and
> they select the download that they want. Of course, this goes away
> if/when the assembly revision is complete.
+1 this is a reasonable compromise.
-dain
Re: More port conflicts
Posted by Joe Bohn <jo...@earthlink.net>.
Dave Colasurdo wrote:
>
>
> David Jencks wrote:
>
>>
>> On Oct 11, 2005, at 4:37 PM, Dave Colasurdo wrote:
>>
>>>
>>>
>>> David Jencks wrote:
>>>
>>>> On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
>>>>
>>>>> Quite frankly, I'm not sure I see the value of having multiple web
>>>>> containers simultaneously active within geronimo. Has anyone heard
>>>>> of a use case or user that is asking for this support?
>>>>
>>>>
>>>> I don't think there is any practical use for it outside of
>>>> experimenting with both web containers at once. It also makes
>>>> running the tck much easier.
>>>>
>>>>> IMHO, I suspect the vast majority of users will choose a single
>>>>> web container (at build or install time) and stick with it. If
>>>>> future requirements dictate a switch to a different container, then
>>>>> laying down a new installation doesn't seem unreasonable. In fact,
>>>>> Geronimo doesn't currently even support incremental maintenance. I
>>>>> would think the use case for non-destructive upgrade would be much
>>>>> more prevalent than changing internal components on the fly.
>>>>>
>>>>> While simultaneous active web containers would be a technical feat,
>>>>> I'm really not sure the overhead and added confusion to users are
>>>>> worth the payoff.. My $.02
>>>>
>>>>
>>>> I prefer to keep this as standard at this point to ensure that our
>>>> architecture remains clean enough to support it. I look forward to
>>>> the installer being sophisticated enough to be able to include the
>>>> correct components for only one web container. At the moment, it
>>>> includes all components and only starts selected ones.
>>>
>>>
>>>
>>> If there is no immediate practical use for it outside of TCK testing,
>>> wouldn't it be beneficial to the users (who are hopefully flocking to
>>> the newly certified J2EE server :>) ) if the default behavior was
>>> more inline with their expectations rather than confuse them with
>>> behavior that is somewhat confusing and that they will likely not be
>>> leveraging?
>>>
>>> The changes to the installer seem like a reasonable plan. How about
>>> users that download the binary zip/tar images? Shouldn't they also
>>> have a simple default way to utilize only one web container. It
>>> seems this is what most users would want. It appears that the
>>> current M5 default behavior is starting both web containers..
>>
>>
>>
>> Well, what do you suggest? At the moment the way to switch to a
>> single web container is to copy 2 text files over 2 other text
>> files. Instructions are in the M5 release notes. The alternative to
>> starting both web containers by default is to start neither: we can't
>> play favorites. We don't yet have a maintainable way of building 2
>> entirely separate distributions. I hope we can get there by 1.0, but
>> it's going to take a substantial revision of our assembly process to
>> use the packaging plugin and the assembly plugin: even with sharing
>> the configurations between distributions it will mean a very
>> substantial increase in maintenance to ship 2 versions, and I am not
>> at all sure it is worth the trouble if we can provide a
>> single-container choice using the installer.
>
>
> Concerning the non-installer images..
>
> Hmmm.. I guess one of the problems is that many folks will not view the
> release notes and just try to use the the application server ( I am
> guilty of this). Some initial thoughts that come to mind to address this:
>
> Binary Distributions (assuming now that G is certified there will be
> more frequent binary images available) - I suspect the audience for
> these binaries will primarily be users and not G developers..
>
> 1) Default to no webcontainer and spell out in BIG BOLD COLORED LETTERS
> ON THE DOWNLOAD SITE that you need to choose a webcontainer via the
> config files. If the server is started w/o a webcontainer, spit out yet
> another reminder message..
>
> 2) Have a separate binary image for both the Jetty and Tomcat
> webcontainers. I'm not suggesting biting off the whole task of revising
> the assembly process but rather just merely having two binaries each
> with a separate set of config files (config.xml, config.list). This
> could even be a post-build step done on the common image. This isn't
> very technically interesting but clearly communicates to users that
> there are two separate environments and they select the download that
> they want. Of course, this goes away if/when the assembly revision is
> complete.
>
> 3) Have no default config in the binaries. Have the jetty and tomcat
> config files available as a separate download (right on the same page as
> the binary images). Clearly document that one of the containers needs
> to be chosen. (I don't like this option)..
>
> 4) Default the binary distribution to one of the web containers. You
> can use MagicGball to decide which one :>) Clearly indicate on the web
> download site that this can easily be changed by updating the config
> files..
>
> While none of these options are too technically exciting, they do
> address the problem of users inadvertently starting G with multiple web
> containers and getting confused. We don't want users to have a bad first
> impression..
>
> Source Tree distributions
>
> Can't there be a simple argument or property that is specified at build
> time to denote which webcontainer (or both) will be used. The build
> will then seed the resulting image with the correct copy of config.list
> and config.xml.. Again this doesn't address the major revision of the
> assembly process but provides a simple way to create an image that has
> the webcontainer(s) config that you want. Hmmm.. perhaps this is
> overkill as developers should already know about config.list and
> config.xml..
>
> Hope I haven't beat this issue to death, just want to try to keep it as
> simple as possible for users...
>
> Thanks
>
As I mentioned in my original note, I too think that we need to provide
some means to ensure just one container is active in the initial
download and provide an easy way for the user to select which one.
However, I don't think that any of the 4 options listed above completely
address the concern because they all seem to keep the configurations for
the non-selected container deployed. #2 is close if we make it a little
bit more sophisticated. In addition to providing two assemblies with
the appropriate config files the post-build processing could also ensure
that the only pre-deployed applications are the ones for the selected
container.
WRT the source tree distribution, we could just make the post-assembly
processing available to as well. The user could choose to keep both
containers (and all configurations) or perform this additional step to
narrow it down to just one container.
Joe
>>
>> 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: More port conflicts
Posted by Dave Colasurdo <da...@earthlink.net>.
David Jencks wrote:
>
> On Oct 11, 2005, at 4:37 PM, Dave Colasurdo wrote:
>
>>
>>
>> David Jencks wrote:
>>
>>> On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
>>>
>>>> Quite frankly, I'm not sure I see the value of having multiple web
>>>> containers simultaneously active within geronimo. Has anyone heard
>>>> of a use case or user that is asking for this support?
>>>
>>> I don't think there is any practical use for it outside of
>>> experimenting with both web containers at once. It also makes
>>> running the tck much easier.
>>>
>>>> IMHO, I suspect the vast majority of users will choose a single
>>>> web container (at build or install time) and stick with it. If
>>>> future requirements dictate a switch to a different container, then
>>>> laying down a new installation doesn't seem unreasonable. In fact,
>>>> Geronimo doesn't currently even support incremental maintenance. I
>>>> would think the use case for non-destructive upgrade would be much
>>>> more prevalent than changing internal components on the fly.
>>>>
>>>> While simultaneous active web containers would be a technical feat,
>>>> I'm really not sure the overhead and added confusion to users are
>>>> worth the payoff.. My $.02
>>>
>>> I prefer to keep this as standard at this point to ensure that our
>>> architecture remains clean enough to support it. I look forward to
>>> the installer being sophisticated enough to be able to include the
>>> correct components for only one web container. At the moment, it
>>> includes all components and only starts selected ones.
>>
>>
>> If there is no immediate practical use for it outside of TCK testing,
>> wouldn't it be beneficial to the users (who are hopefully flocking to
>> the newly certified J2EE server :>) ) if the default behavior was more
>> inline with their expectations rather than confuse them with behavior
>> that is somewhat confusing and that they will likely not be leveraging?
>>
>> The changes to the installer seem like a reasonable plan. How about
>> users that download the binary zip/tar images? Shouldn't they also
>> have a simple default way to utilize only one web container. It seems
>> this is what most users would want. It appears that the current M5
>> default behavior is starting both web containers..
>
>
> Well, what do you suggest? At the moment the way to switch to a single
> web container is to copy 2 text files over 2 other text files.
> Instructions are in the M5 release notes. The alternative to starting
> both web containers by default is to start neither: we can't play
> favorites. We don't yet have a maintainable way of building 2 entirely
> separate distributions. I hope we can get there by 1.0, but it's going
> to take a substantial revision of our assembly process to use the
> packaging plugin and the assembly plugin: even with sharing the
> configurations between distributions it will mean a very substantial
> increase in maintenance to ship 2 versions, and I am not at all sure it
> is worth the trouble if we can provide a single-container choice using
> the installer.
Concerning the non-installer images..
Hmmm.. I guess one of the problems is that many folks will not view the
release notes and just try to use the the application server ( I am
guilty of this). Some initial thoughts that come to mind to address this:
Binary Distributions (assuming now that G is certified there will be
more frequent binary images available) - I suspect the audience for
these binaries will primarily be users and not G developers..
1) Default to no webcontainer and spell out in BIG BOLD COLORED LETTERS
ON THE DOWNLOAD SITE that you need to choose a webcontainer via the
config files. If the server is started w/o a webcontainer, spit out yet
another reminder message..
2) Have a separate binary image for both the Jetty and Tomcat
webcontainers. I'm not suggesting biting off the whole task of revising
the assembly process but rather just merely having two binaries each
with a separate set of config files (config.xml, config.list). This
could even be a post-build step done on the common image. This isn't
very technically interesting but clearly communicates to users that
there are two separate environments and they select the download that
they want. Of course, this goes away if/when the assembly revision is
complete.
3) Have no default config in the binaries. Have the jetty and tomcat
config files available as a separate download (right on the same page as
the binary images). Clearly document that one of the containers needs
to be chosen. (I don't like this option)..
4) Default the binary distribution to one of the web containers. You
can use MagicGball to decide which one :>) Clearly indicate on the web
download site that this can easily be changed by updating the config files..
While none of these options are too technically exciting, they do
address the problem of users inadvertently starting G with multiple web
containers and getting confused. We don't want users to have a bad first
impression..
Source Tree distributions
Can't there be a simple argument or property that is specified at build
time to denote which webcontainer (or both) will be used. The build
will then seed the resulting image with the correct copy of config.list
and config.xml.. Again this doesn't address the major revision of the
assembly process but provides a simple way to create an image that has
the webcontainer(s) config that you want. Hmmm.. perhaps this is
overkill as developers should already know about config.list and
config.xml..
Hope I haven't beat this issue to death, just want to try to keep it as
simple as possible for users...
Thanks
>
> thanks
> david jencks
>
>
>
>
Re: More port conflicts
Posted by David Jencks <da...@yahoo.com>.
On Oct 11, 2005, at 4:37 PM, Dave Colasurdo wrote:
>
>
> David Jencks wrote:
>> On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
>>> Quite frankly, I'm not sure I see the value of having multiple web
>>> containers simultaneously active within geronimo. Has anyone heard
>>> of a use case or user that is asking for this support?
>> I don't think there is any practical use for it outside of
>> experimenting with both web containers at once. It also makes
>> running the tck much easier.
>>
>>> IMHO, I suspect the vast majority of users will choose a single
>>> web container (at build or install time) and stick with it. If
>>> future requirements dictate a switch to a different container, then
>>> laying down a new installation doesn't seem unreasonable. In fact,
>>> Geronimo doesn't currently even support incremental maintenance. I
>>> would think the use case for non-destructive upgrade would be much
>>> more prevalent than changing internal components on the fly.
>>>
>>> While simultaneous active web containers would be a technical feat,
>>> I'm really not sure the overhead and added confusion to users are
>>> worth the payoff.. My $.02
>> I prefer to keep this as standard at this point to ensure that our
>> architecture remains clean enough to support it. I look forward to
>> the installer being sophisticated enough to be able to include the
>> correct components for only one web container. At the moment, it
>> includes all components and only starts selected ones.
>
> If there is no immediate practical use for it outside of TCK testing,
> wouldn't it be beneficial to the users (who are hopefully flocking to
> the newly certified J2EE server :>) ) if the default behavior was more
> inline with their expectations rather than confuse them with behavior
> that is somewhat confusing and that they will likely not be
> leveraging?
>
> The changes to the installer seem like a reasonable plan. How about
> users that download the binary zip/tar images? Shouldn't they also
> have a simple default way to utilize only one web container. It seems
> this is what most users would want. It appears that the current M5
> default behavior is starting both web containers..
Well, what do you suggest? At the moment the way to switch to a single
web container is to copy 2 text files over 2 other text files.
Instructions are in the M5 release notes. The alternative to starting
both web containers by default is to start neither: we can't play
favorites. We don't yet have a maintainable way of building 2 entirely
separate distributions. I hope we can get there by 1.0, but it's going
to take a substantial revision of our assembly process to use the
packaging plugin and the assembly plugin: even with sharing the
configurations between distributions it will mean a very substantial
increase in maintenance to ship 2 versions, and I am not at all sure it
is worth the trouble if we can provide a single-container choice using
the installer.
thanks
david jencks
Re: More port conflicts
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
To give my 2 cents on this thread:
- It's true that the startup sequence reports the port of the first
connector it finds no matter what. We need a way to associate
applications with containers. I looked to see about registering a
dependency during deployment, but it wasn't obvious how the deployer
knew what container it was deploying to. If someone can spell that
out for me, I'll make the startup report work.
- I don't think it's very good to distribute a build with both
containers present and active. (as far as end users go; TCK testing
with that build is fine.) I think the easiest path forward is a
post-processing step that starts with the current assembly output,
puts in a proper config.xml, and undeploys the stuff for the server
it's not using.
- I don't much like the idea of having separate startup scripts for
separate containers. The problem is, if there are two there, how are
you sure that the user is always going to use the right one?
- It would also be possible to ship by default with nothing enabled
but a special GBean that would prompt you for which configuration you
want, copy in the right config file accordingly (which would not
include itself), and shut down the server. So the first time you run
it would start practically nothing, ask whether you want Tomcat or
Jetty, tell you that the server has been configured and you need to
restart it, then shut down. This would not be necessary if you used
the installer, only the ZIP.
- It would be nice if the installer could force you to pick Tomcat or
Jetty but not both -- but I don't think IzPack has "radio button"
equivalents for the package selection screen. But we can probably
hack it to offer port selections for both servers (if both are
selected) and barf if any of them conflict.
Aaron
On 10/12/05, Matt Hogstrom <ma...@hogstrom.org> wrote:
> com> <43...@earthlink.net> <8E...@iq80.com> <6c...@yahoo.com>
> In-Reply-To: <6c...@yahoo.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Content-Transfer-Encoding: 7bit
> X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
> X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
> X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
>
> I like this better. See my other note as to updating the Welcome Page.
>
> +1
>
> David Jencks wrote:
> >
> > On Oct 12, 2005, at 11:48 AM, Dain Sundstrom wrote:
> >
> >>
> >> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
> >>
> >>> 2) Have a separate binary image for both the Jetty and Tomcat
> >>> webcontainers. I'm not suggesting biting off the whole task of
> >>> revising the assembly process but rather just merely having two
> >>> binaries each with a separate set of config files (config.xml,
> >>> config.list). This could even be a post-build step done on the
> >>> common image. This isn't very technically interesting but clearly
> >>> communicates to users that there are two separate environments and
> >>> they select the download that they want. Of course, this goes away
> >>> if/when the assembly revision is complete.
> >>
> >>
> >> +1 this is a reasonable compromise.
> >>
> >
> > OK, one more idea for the list...
> >
> > I'm into testing on making config.xml serve as both the attribute store
> > and the persistent configuration list. When this works, I think it
> > would be useful to have a command line parameter that sets the
> > location/name of the config.xml file to use (maybe a system property).
> > Then we could choose the configuration on the command line
> >
> > java -jar bin/server.jar -Dgeronimo.configuration=geronimo-jetty.xml
> >
> > Scripts could remove the need to know the file name :-)
> >
> > ./geronimo-jetty
> >
> > Would this be adequate and remove the need for separate distributions?
> >
> > thanks
> > david jencks
> >
> >
> >
> >
>
>
Re: More port conflicts
Posted by Matt Hogstrom <ma...@hogstrom.org>.
com> <43...@earthlink.net> <8E...@iq80.com> <6c...@yahoo.com>
In-Reply-To: <6c...@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
I like this better. See my other note as to updating the Welcome Page.
+1
David Jencks wrote:
>
> On Oct 12, 2005, at 11:48 AM, Dain Sundstrom wrote:
>
>>
>> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
>>
>>> 2) Have a separate binary image for both the Jetty and Tomcat
>>> webcontainers. I'm not suggesting biting off the whole task of
>>> revising the assembly process but rather just merely having two
>>> binaries each with a separate set of config files (config.xml,
>>> config.list). This could even be a post-build step done on the
>>> common image. This isn't very technically interesting but clearly
>>> communicates to users that there are two separate environments and
>>> they select the download that they want. Of course, this goes away
>>> if/when the assembly revision is complete.
>>
>>
>> +1 this is a reasonable compromise.
>>
>
> OK, one more idea for the list...
>
> I'm into testing on making config.xml serve as both the attribute store
> and the persistent configuration list. When this works, I think it
> would be useful to have a command line parameter that sets the
> location/name of the config.xml file to use (maybe a system property).
> Then we could choose the configuration on the command line
>
> java -jar bin/server.jar -Dgeronimo.configuration=geronimo-jetty.xml
>
> Scripts could remove the need to know the file name :-)
>
> ./geronimo-jetty
>
> Would this be adequate and remove the need for separate distributions?
>
> thanks
> david jencks
>
>
>
>
Re: More port conflicts
Posted by Matt Hogstrom <ma...@hogstrom.org>.
com> <43...@earthlink.net> <8E...@iq80.com>
In-Reply-To: <8E...@iq80.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1
X-MMS-Smtp-Auth: Authenticated As matt@hogstrom.org
X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1
I don't have a good pulse on the "majority of users" but I would suggest we
switch to Tomcat as the default (Jetty has probably had most of its bugs worked
out by now) and update the Welcome page with instructions on how to switch (or
point them to the Release notes) and we focus on resolving this issue in the
installer for 1.0?
- Matt
Dain Sundstrom wrote:
>
> On Oct 11, 2005, at 7:41 PM, Dave Colasurdo wrote:
>
>> 2) Have a separate binary image for both the Jetty and Tomcat
>> webcontainers. I'm not suggesting biting off the whole task of
>> revising the assembly process but rather just merely having two
>> binaries each with a separate set of config files (config.xml,
>> config.list). This could even be a post-build step done on the
>> common image. This isn't very technically interesting but clearly
>> communicates to users that there are two separate environments and
>> they select the download that they want. Of course, this goes away
>> if/when the assembly revision is complete.
>
>
> +1 this is a reasonable compromise.
>
> -dain
>
>
>
Re: More port conflicts
Posted by Dave Colasurdo <da...@earthlink.net>.
David Jencks wrote:
>
> On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
>
>> Quite frankly, I'm not sure I see the value of having multiple web
>> containers simultaneously active within geronimo. Has anyone heard of
>> a use case or user that is asking for this support?
>
>
> I don't think there is any practical use for it outside of experimenting
> with both web containers at once. It also makes running the tck much
> easier.
>
>> IMHO, I suspect the vast majority of users will choose a single web
>> container (at build or install time) and stick with it. If future
>> requirements dictate a switch to a different container, then laying
>> down a new installation doesn't seem unreasonable. In fact, Geronimo
>> doesn't currently even support incremental maintenance. I would think
>> the use case for non-destructive upgrade would be much more prevalent
>> than changing internal components on the fly.
>>
>> While simultaneous active web containers would be a technical feat,
>> I'm really not sure the overhead and added confusion to users are
>> worth the payoff.. My $.02
>
>
> I prefer to keep this as standard at this point to ensure that our
> architecture remains clean enough to support it. I look forward to the
> installer being sophisticated enough to be able to include the correct
> components for only one web container. At the moment, it includes all
> components and only starts selected ones.
>
If there is no immediate practical use for it outside of TCK testing,
wouldn't it be beneficial to the users (who are hopefully flocking to
the newly certified J2EE server :>) ) if the default behavior was more
inline with their expectations rather than confuse them with behavior
that is somewhat confusing and that they will likely not be leveraging?
The changes to the installer seem like a reasonable plan. How about
users that download the binary zip/tar images? Shouldn't they also have
a simple default way to utilize only one web container. It seems this
is what most users would want. It appears that the current M5 default
behavior is starting both web containers..
Thanks
> thanks
> david jencks
>
>>
>> Thanks
>> Dave
>>
>>
>> Joe Bohn wrote:
>>
>>> I know I keep beating on this but IMO this is another problem of the
>>> multiple container configuration and single image delivery. It would
>>> be equally problematic to attempt to start both the tomcat & jetty
>>> console or welcome configurations simultaneously even in just a
>>> single container configuration. I think we will have problems like
>>> this until we come to the point where we deliver two images that
>>> include only the peripheral configurations that are applicable to the
>>> particular image (one for tomcat and one for jetty).
>>> I'm willing to eat my words if I hear a proposal on how we can avoid
>>> problems like these. I just don't see a clear solution to problems
>>> with our current approach unless we get a lot more sophisticated with
>>> conversion capability (and even then I think the user will be
>>> confused when s/he sees multiple configurations for the same
>>> applications even if they all work).
>>> Joe
>>> anita kulshreshtha wrote:
>>>
>>>> I have built M5 from the source. I am running the
>>>> default configuration (Jetty and Tomcat). I start The
>>>> following configurations :
>>>> org/apache/geronimo/applications/Welcome/Tomcat and
>>>> org/apache/geronimo/Console/Tomcat Both theses configurations
>>>> get started on port
>>>> 8080. Even though Tomcat is running on port 8090: Before I
>>>> investigate further, is this a known
>>>> problem?
>>>>
>>>> Thanks
>>>> Anita
>>>>
>>>>
>>>> __________________________________ Yahoo! Mail - PC
>>>> Magazine Editors' Choice 2005 http://mail.yahoo.com
>>>>
>>>>
>>
>
>
>
Re: More port conflicts
Posted by David Jencks <da...@yahoo.com>.
On Oct 11, 2005, at 2:18 PM, Dave Colasurdo wrote:
> Quite frankly, I'm not sure I see the value of having multiple web
> containers simultaneously active within geronimo. Has anyone heard of
> a use case or user that is asking for this support?
I don't think there is any practical use for it outside of
experimenting with both web containers at once. It also makes running
the tck much easier.
> IMHO, I suspect the vast majority of users will choose a single web
> container (at build or install time) and stick with it. If future
> requirements dictate a switch to a different container, then laying
> down a new installation doesn't seem unreasonable. In fact, Geronimo
> doesn't currently even support incremental maintenance. I would think
> the use case for non-destructive upgrade would be much more prevalent
> than changing internal components on the fly.
>
> While simultaneous active web containers would be a technical feat,
> I'm really not sure the overhead and added confusion to users are
> worth the payoff.. My $.02
I prefer to keep this as standard at this point to ensure that our
architecture remains clean enough to support it. I look forward to the
installer being sophisticated enough to be able to include the correct
components for only one web container. At the moment, it includes all
components and only starts selected ones.
thanks
david jencks
>
> Thanks
> Dave
>
>
> Joe Bohn wrote:
>> I know I keep beating on this but IMO this is another problem of the
>> multiple container configuration and single image delivery. It would
>> be equally problematic to attempt to start both the tomcat & jetty
>> console or welcome configurations simultaneously even in just a
>> single container configuration. I think we will have problems like
>> this until we come to the point where we deliver two images that
>> include only the peripheral configurations that are applicable to the
>> particular image (one for tomcat and one for jetty).
>> I'm willing to eat my words if I hear a proposal on how we can avoid
>> problems like these. I just don't see a clear solution to problems
>> with our current approach unless we get a lot more sophisticated with
>> conversion capability (and even then I think the user will be
>> confused when s/he sees multiple configurations for the same
>> applications even if they all work).
>> Joe
>> anita kulshreshtha wrote:
>>> I have built M5 from the source. I am running the
>>> default configuration (Jetty and Tomcat). I start The
>>> following configurations :
>>> org/apache/geronimo/applications/Welcome/Tomcat and
>>> org/apache/geronimo/Console/Tomcat Both theses configurations
>>> get started on port
>>> 8080. Even though Tomcat is running on port 8090: Before I
>>> investigate further, is this a known
>>> problem?
>>>
>>> Thanks
>>> Anita
>>>
>>>
>>> __________________________________ Yahoo! Mail - PC
>>> Magazine Editors' Choice 2005 http://mail.yahoo.com
>>>
>>>
>
Re: More port conflicts
Posted by Dave Colasurdo <da...@earthlink.net>.
Quite frankly, I'm not sure I see the value of having multiple web
containers simultaneously active within geronimo. Has anyone heard of a
use case or user that is asking for this support? IMHO, I suspect the
vast majority of users will choose a single web container (at build or
install time) and stick with it. If future requirements dictate a
switch to a different container, then laying down a new installation
doesn't seem unreasonable. In fact, Geronimo doesn't currently even
support incremental maintenance. I would think the use case for
non-destructive upgrade would be much more prevalent than changing
internal components on the fly.
While simultaneous active web containers would be a technical feat, I'm
really not sure the overhead and added confusion to users are worth the
payoff.. My $.02
Thanks
Dave
Joe Bohn wrote:
>
> I know I keep beating on this but IMO this is another problem of the
> multiple container configuration and single image delivery. It would be
> equally problematic to attempt to start both the tomcat & jetty console
> or welcome configurations simultaneously even in just a single container
> configuration. I think we will have problems like this until we come to
> the point where we deliver two images that include only the peripheral
> configurations that are applicable to the particular image (one for
> tomcat and one for jetty).
>
> I'm willing to eat my words if I hear a proposal on how we can avoid
> problems like these. I just don't see a clear solution to problems with
> our current approach unless we get a lot more sophisticated with
> conversion capability (and even then I think the user will be confused
> when s/he sees multiple configurations for the same applications even if
> they all work).
>
> Joe
>
>
> anita kulshreshtha wrote:
>
>> I have built M5 from the source. I am running the
>> default configuration (Jetty and Tomcat). I start The
>> following configurations :
>> org/apache/geronimo/applications/Welcome/Tomcat and
>> org/apache/geronimo/Console/Tomcat Both theses configurations get
>> started on port
>> 8080. Even though Tomcat is running on port 8090: Before I
>> investigate further, is this a known
>> problem?
>>
>> Thanks
>> Anita
>>
>>
>>
>>
>> __________________________________ Yahoo! Mail - PC Magazine Editors'
>> Choice 2005 http://mail.yahoo.com
>>
>>
>
Re: More port conflicts
Posted by Joe Bohn <jo...@earthlink.net>.
I know I keep beating on this but IMO this is another problem of the
multiple container configuration and single image delivery. It would be
equally problematic to attempt to start both the tomcat & jetty console
or welcome configurations simultaneously even in just a single container
configuration. I think we will have problems like this until we come to
the point where we deliver two images that include only the peripheral
configurations that are applicable to the particular image (one for
tomcat and one for jetty).
I'm willing to eat my words if I hear a proposal on how we can avoid
problems like these. I just don't see a clear solution to problems with
our current approach unless we get a lot more sophisticated with
conversion capability (and even then I think the user will be confused
when s/he sees multiple configurations for the same applications even if
they all work).
Joe
anita kulshreshtha wrote:
> I have built M5 from the source. I am running the
> default configuration (Jetty and Tomcat). I start The
> following configurations :
> org/apache/geronimo/applications/Welcome/Tomcat and
> org/apache/geronimo/Console/Tomcat
> Both theses configurations get started on port
> 8080. Even though Tomcat is running on port 8090:
> Before I investigate further, is this a known
> problem?
>
> Thanks
> Anita
>
>
>
>
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot
lose." -- Jim Elliot