You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2005/07/28 02:44:48 UTC
Jetty Max Threads Patch
Matt,
If you're up to it, can you submit an additional patch for the
Jetty connectors to fully implement
modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnector.java
I've verified that the underlying product supports all the methods
in there (I put the URLs in the JavaDoc). There's also a
SecureConnector.java interface in the same dir for the SSL connector.
Thanks,
Aaron
Re: Jetty Max Threads Patch
Posted by Jeff Genender <jg...@savoirtech.com>.
David Jencks wrote:
> You might look at the dynamic attributes used in
> ManagedConnectionFactoryWrapper, AdminObjectWrapper, and
> ResourceAdapterWrapper. They require some xml up front from ra.xml to
> determine the exposed properties, but don't require extra
> code/implementation class.
I'll have a look.
> I am still not happy with the idea of
> exposing stuff purely by reflection without a definite indication of
> some sort that it is really intended to be exposed.
>
In this instance it should not be an issue. I basically extended what
is done already today in Tomcat. The Tomcat digester runs all of its
xml parameters as found in the server.xml and context.xml through the
IntrospectionUtils, and thus it operates on properties purely through
reflection. I am simply doing the same with the Gbeans. The last thing
I want to do is take away functionality from the Tomcat piece. We
should be minimally matching this functionality. Without allowing for
dynamic attributes or properties through reflection, we would be taking
away functionality from Tomcat. If you can come up with a better way, I
would love to hear about it...but I honestly cannot see any other
alternative.
Jeff
> david jencks
>
> On Jul 27, 2005, at 8:53 PM, Jeff Genender wrote:
>
>>
>>
>> Aaron Mulder wrote:
>>
>>> On Wed, 27 Jul 2005, Jeff Genender wrote:
>>>
>>>> For subclassing to make an SSL Gbean, I am against this...this
>>>> nails up a particular connector GBean, where what I have allows
>>>> the connector to be used for just that...a connector...any
>>>> protocol, etc, makes no difference here. The Connector
>>>> architecture I have implemented allows for a direct pass through to
>>>> Tomcat's Connector object, and thus makes it as flexible as possible.
>>>
>>> Here's the problem: if ConnectorGBean offers SSL settings, you're
>>> offered the opportunity to provide/configure a bunch of stuff that is
>>> totally irrelevant to a non-SSL connector (you know, user views an HTTP
>>> connector, it asks them for a keystore -- what's up with that?). I
>>> don't
>>> believe we should offer configuration and management setting that don't
>>> apply.
>>> So, I'd prefer to do this:
>>> ConnectorGBean
>>> - all connector code
>>> - non-SSL config options
>>> SSLConnectorGBean extends ConnectorGBean
>>> - no additional connector code (config/mgmt only)
>>> - always sets secure=true
>>> - includes SSL config options (inherits non-SSL config options)
>>> - ultimately can refer to an external keystore GBean
>>
>>
>> What about AJP? I guess its fine to subclass as long as the
>> ConnectorGBean is available, so other types of connectors could be
>> created.
>>
>>> That wat if you go to manage a HTTP connector, it has only
>>> settings pertinent to an HTTP connector, and if you go to manage an
>>> HTTPS connector is has all the settings pertinent to an HTTPS
>>> connector.
>>> Again, I'm not at all suggesting that we split up the code that
>>> deals with the underlying Tomcat objects.
>>
>>
>> Good...this was really my main concern.
>>
>>>> If this is something you want to occur, then I would appreciate
>>>> that this is opened up for discussion before anyone goes
>>>> subclassing the ConnectorGBean.
>>>
>>> Sorry -- I thought I wrote to the list about this aready, but it
>>> was stuck in my postponed messages. Here was my original thought on
>>> the topic.
>>
>>
>> Now things make sense ;-) But I am addressing one area ... comments
>> inline below.
>>
>>> Aaron
>>> -------------------
>>> So as part of this management API, I'd like to move a bunch of
>>> properties out of the "initParams" and into separate properties for the
>>> Tomcat connectors. Then those properties can be reflected in the
>>> management interface.
>>> One issue is that all connectors seem to support the same
>>> settings
>>> -- in particular, the SSL settings, which I guess are just ignored
>>> unless
>>> the secure flag is set. But it doesn't make sense to me to offer SSL
>>> management properties for HTTP connectors.
>>> That being the case, I'd like to break out an SSLConnectorGBean
>>> from the ConnectorGBean. The SSL version would just extend the basic
>>> one, add more manageable properties, and default the secure flag to
>>> true.
>>> For now, you could still configure a SSL connector using the
>>> standard ConectorGBean just to frustrate me, but eventually I'd like to
>>> move all the connector properties into GBean properties and remove the
>>> initParams all together.
>>
>>
>> That will be a problem in the future. The whole idea about the
>> initParams is it allows you to plug in other "beans" and the GBean
>> will dynamically set the properties through introspection without
>> having to write a GBean that nails up an attribute to a class
>> property. I think its ok to do this with SSL, etc, but an accross
>> the board cut of the initparams would force us to write a new GBean
>> if I have a new connector object (or new Valve or Realm or Host).
>>
>> I originally was doing a one for one Gbean attribute to class
>> parameter when I started Tomcat. But this became unfeasible when I
>> noticed the whole Tomcat architecture revolved around pluggable
>> components that introspect the component properties. No one single
>> Valve or Realm fit ... they seemed to have different properties based
>> upon the class used. Introspection was the cure. Now we can use any
>> kind of connector/Valve/Realm/Host/Engine by declaring the class name
>> and setting initParams...Gbean will introspect...and it works.
>>
>> What I would suggest perhaps is to look at this from a bigger picture
>> and review the way Gbeans work with attributes, and would there be a
>> way to allow for dynamic parameters w/o the need to explicitly code
>> the attributes. Some form of introspection would be ideal (as I am
>> currently using in the Tomcat Gbeans). This way we can make
>> pluggable pojo classes that allow for dynamically configurable
>> properties. Perhaps the Spring kernel will allow this?
>>
>> Jeff
>>
>>>>> On Wed, 27 Jul 2005, Matt Hogstrom wrote:
>>>>>
>>>>>
>>>>>> I was going to do that tonight or tomorrow and give Tomcat the
>>>>>> same lovin.
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> ----- Original Message ----- From: "Aaron Mulder"
>>>>>> <am...@alumni.princeton.edu>
>>>>>> To: <de...@geronimo.apache.org>
>>>>>> Sent: Wednesday, July 27, 2005 8:44 PM
>>>>>> Subject: Jetty Max Threads Patch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Matt,
>>>>>>> If you're up to it, can you submit an additional patch for the
>>>>>>> Jetty connectors to fully implement
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> modules/j2ee/src/java/org/apache/geronimo/j2ee/management/
>>>>>> geronimo/WebConnec
>>>>>> tor.java
>>>>>>
>>>>>>
>>>>>>> I've verified that the underlying product supports all the methods
>>>>>>> in there (I put the URLs in the JavaDoc). There's also a
>>>>>>> SecureConnector.java interface in the same dir for the SSL
>>>>>>> connector.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Aaron
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
Re: Jetty Max Threads Patch
Posted by David Jencks <dj...@gluecode.com>.
You might look at the dynamic attributes used in
ManagedConnectionFactoryWrapper, AdminObjectWrapper, and
ResourceAdapterWrapper. They require some xml up front from ra.xml to
determine the exposed properties, but don't require extra
code/implementation class. I am still not happy with the idea of
exposing stuff purely by reflection without a definite indication of
some sort that it is really intended to be exposed.
david jencks
On Jul 27, 2005, at 8:53 PM, Jeff Genender wrote:
>
>
> Aaron Mulder wrote:
>> On Wed, 27 Jul 2005, Jeff Genender wrote:
>>> For subclassing to make an SSL Gbean, I am against this...this nails
>>> up a particular connector GBean, where what I have allows the
>>> connector to be used for just that...a connector...any protocol,
>>> etc, makes no difference here. The Connector architecture I have
>>> implemented allows for a direct pass through to Tomcat's Connector
>>> object, and thus makes it as flexible as possible.
>> Here's the problem: if ConnectorGBean offers SSL settings, you're
>> offered the opportunity to provide/configure a bunch of stuff that is
>> totally irrelevant to a non-SSL connector (you know, user views an
>> HTTP
>> connector, it asks them for a keystore -- what's up with that?). I
>> don't
>> believe we should offer configuration and management setting that
>> don't
>> apply.
>> So, I'd prefer to do this:
>> ConnectorGBean
>> - all connector code
>> - non-SSL config options
>> SSLConnectorGBean extends ConnectorGBean
>> - no additional connector code (config/mgmt only)
>> - always sets secure=true
>> - includes SSL config options (inherits non-SSL config options)
>> - ultimately can refer to an external keystore GBean
>
> What about AJP? I guess its fine to subclass as long as the
> ConnectorGBean is available, so other types of connectors could be
> created.
>
>> That wat if you go to manage a HTTP connector, it has only settings
>> pertinent to an HTTP connector, and if you go to manage an HTTPS
>> connector is has all the settings pertinent to an HTTPS connector.
>> Again, I'm not at all suggesting that we split up the code that
>> deals with the underlying Tomcat objects.
>
> Good...this was really my main concern.
>
>>> If this is something you want to occur, then I would appreciate that
>>> this is opened up for discussion before anyone goes subclassing the
>>> ConnectorGBean.
>> Sorry -- I thought I wrote to the list about this aready, but it was
>> stuck in my postponed messages. Here was my original thought on the
>> topic.
>
> Now things make sense ;-) But I am addressing one area ... comments
> inline below.
>
>> Aaron
>> -------------------
>> So as part of this management API, I'd like to move a bunch of
>> properties out of the "initParams" and into separate properties for
>> the
>> Tomcat connectors. Then those properties can be reflected in the
>> management interface.
>> One issue is that all connectors seem to support the same
>> settings
>> -- in particular, the SSL settings, which I guess are just ignored
>> unless
>> the secure flag is set. But it doesn't make sense to me to offer SSL
>> management properties for HTTP connectors.
>> That being the case, I'd like to break out an
>> SSLConnectorGBean
>> from the ConnectorGBean. The SSL version would just extend the basic
>> one, add more manageable properties, and default the secure flag to
>> true.
>> For now, you could still configure a SSL connector using the
>> standard ConectorGBean just to frustrate me, but eventually I'd like
>> to
>> move all the connector properties into GBean properties and remove the
>> initParams all together.
>
> That will be a problem in the future. The whole idea about the
> initParams is it allows you to plug in other "beans" and the GBean
> will dynamically set the properties through introspection without
> having to write a GBean that nails up an attribute to a class
> property. I think its ok to do this with SSL, etc, but an accross the
> board cut of the initparams would force us to write a new GBean if I
> have a new connector object (or new Valve or Realm or Host).
>
> I originally was doing a one for one Gbean attribute to class
> parameter when I started Tomcat. But this became unfeasible when I
> noticed the whole Tomcat architecture revolved around pluggable
> components that introspect the component properties. No one single
> Valve or Realm fit ... they seemed to have different properties based
> upon the class used. Introspection was the cure. Now we can use any
> kind of connector/Valve/Realm/Host/Engine by declaring the class name
> and setting initParams...Gbean will introspect...and it works.
>
> What I would suggest perhaps is to look at this from a bigger picture
> and review the way Gbeans work with attributes, and would there be a
> way to allow for dynamic parameters w/o the need to explicitly code
> the attributes. Some form of introspection would be ideal (as I am
> currently using in the Tomcat Gbeans). This way we can make pluggable
> pojo classes that allow for dynamically configurable properties.
> Perhaps the Spring kernel will allow this?
>
> Jeff
>
>>>> On Wed, 27 Jul 2005, Matt Hogstrom wrote:
>>>>
>>>>
>>>>> I was going to do that tonight or tomorrow and give Tomcat the
>>>>> same lovin.
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Aaron Mulder"
>>>>> <am...@alumni.princeton.edu>
>>>>> To: <de...@geronimo.apache.org>
>>>>> Sent: Wednesday, July 27, 2005 8:44 PM
>>>>> Subject: Jetty Max Threads Patch
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Matt,
>>>>>> If you're up to it, can you submit an additional patch for the
>>>>>> Jetty connectors to fully implement
>>>>>>
>>>>>>
>>>>>
>>>>> modules/j2ee/src/java/org/apache/geronimo/j2ee/management/
>>>>> geronimo/WebConnec
>>>>> tor.java
>>>>>
>>>>>
>>>>>> I've verified that the underlying product supports all the methods
>>>>>> in there (I put the URLs in the JavaDoc). There's also a
>>>>>> SecureConnector.java interface in the same dir for the SSL
>>>>>> connector.
>>>>>>
>>>>>> Thanks,
>>>>>> Aaron
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>
Re: Jetty Max Threads Patch
Posted by Jeff Genender <jg...@savoirtech.com>.
Aaron Mulder wrote:
> On Wed, 27 Jul 2005, Jeff Genender wrote:
>
>>For subclassing to make an SSL Gbean, I am against this...this nails up
>>a particular connector GBean, where what I have allows the connector to
>>be used for just that...a connector...any protocol, etc, makes no
>>difference here. The Connector architecture I have implemented allows
>>for a direct pass through to Tomcat's Connector object, and thus makes
>>it as flexible as possible.
>
>
> Here's the problem: if ConnectorGBean offers SSL settings, you're
> offered the opportunity to provide/configure a bunch of stuff that is
> totally irrelevant to a non-SSL connector (you know, user views an HTTP
> connector, it asks them for a keystore -- what's up with that?). I don't
> believe we should offer configuration and management setting that don't
> apply.
>
> So, I'd prefer to do this:
>
> ConnectorGBean
> - all connector code
> - non-SSL config options
>
> SSLConnectorGBean extends ConnectorGBean
> - no additional connector code (config/mgmt only)
> - always sets secure=true
> - includes SSL config options (inherits non-SSL config options)
> - ultimately can refer to an external keystore GBean
What about AJP? I guess its fine to subclass as long as the
ConnectorGBean is available, so other types of connectors could be created.
>
> That wat if you go to manage a HTTP connector, it has only
> settings pertinent to an HTTP connector, and if you go to manage an HTTPS
> connector is has all the settings pertinent to an HTTPS connector.
>
> Again, I'm not at all suggesting that we split up the code that
> deals with the underlying Tomcat objects.
Good...this was really my main concern.
>
>
>>If this is something you want to occur, then I would appreciate that
>>this is opened up for discussion before anyone goes subclassing the
>>ConnectorGBean.
>
>
> Sorry -- I thought I wrote to the list about this aready, but it
> was stuck in my postponed messages. Here was my original thought on the
> topic.
Now things make sense ;-) But I am addressing one area ... comments
inline below.
>
> Aaron
>
> -------------------
>
> So as part of this management API, I'd like to move a bunch of
> properties out of the "initParams" and into separate properties for the
> Tomcat connectors. Then those properties can be reflected in the
> management interface.
>
> One issue is that all connectors seem to support the same settings
> -- in particular, the SSL settings, which I guess are just ignored unless
> the secure flag is set. But it doesn't make sense to me to offer SSL
> management properties for HTTP connectors.
>
> That being the case, I'd like to break out an SSLConnectorGBean
> from the ConnectorGBean. The SSL version would just extend the basic
> one, add more manageable properties, and default the secure flag to true.
>
> For now, you could still configure a SSL connector using the
> standard ConectorGBean just to frustrate me, but eventually I'd like to
> move all the connector properties into GBean properties and remove the
> initParams all together.
That will be a problem in the future. The whole idea about the
initParams is it allows you to plug in other "beans" and the GBean will
dynamically set the properties through introspection without having to
write a GBean that nails up an attribute to a class property. I think
its ok to do this with SSL, etc, but an accross the board cut of the
initparams would force us to write a new GBean if I have a new connector
object (or new Valve or Realm or Host).
I originally was doing a one for one Gbean attribute to class parameter
when I started Tomcat. But this became unfeasible when I noticed the
whole Tomcat architecture revolved around pluggable components that
introspect the component properties. No one single Valve or Realm fit
... they seemed to have different properties based upon the class used.
Introspection was the cure. Now we can use any kind of
connector/Valve/Realm/Host/Engine by declaring the class name and
setting initParams...Gbean will introspect...and it works.
What I would suggest perhaps is to look at this from a bigger picture
and review the way Gbeans work with attributes, and would there be a way
to allow for dynamic parameters w/o the need to explicitly code the
attributes. Some form of introspection would be ideal (as I am
currently using in the Tomcat Gbeans). This way we can make pluggable
pojo classes that allow for dynamically configurable properties.
Perhaps the Spring kernel will allow this?
Jeff
>
>
>
>
>>>On Wed, 27 Jul 2005, Matt Hogstrom wrote:
>>>
>>>
>>>>I was going to do that tonight or tomorrow and give Tomcat the same lovin.
>>>>
>>>>Matt
>>>>
>>>>
>>>>----- Original Message -----
>>>>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>>>>To: <de...@geronimo.apache.org>
>>>>Sent: Wednesday, July 27, 2005 8:44 PM
>>>>Subject: Jetty Max Threads Patch
>>>>
>>>>
>>>>
>>>>
>>>>>Matt,
>>>>>If you're up to it, can you submit an additional patch for the
>>>>>Jetty connectors to fully implement
>>>>>
>>>>>
>>>>
>>>>modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
>>>>tor.java
>>>>
>>>>
>>>>>I've verified that the underlying product supports all the methods
>>>>>in there (I put the URLs in the JavaDoc). There's also a
>>>>>SecureConnector.java interface in the same dir for the SSL connector.
>>>>>
>>>>>Thanks,
>>>>>Aaron
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
Re: Jetty Max Threads Patch
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Wed, 27 Jul 2005, Jeff Genender wrote:
> For subclassing to make an SSL Gbean, I am against this...this nails up
> a particular connector GBean, where what I have allows the connector to
> be used for just that...a connector...any protocol, etc, makes no
> difference here. The Connector architecture I have implemented allows
> for a direct pass through to Tomcat's Connector object, and thus makes
> it as flexible as possible.
Here's the problem: if ConnectorGBean offers SSL settings, you're
offered the opportunity to provide/configure a bunch of stuff that is
totally irrelevant to a non-SSL connector (you know, user views an HTTP
connector, it asks them for a keystore -- what's up with that?). I don't
believe we should offer configuration and management setting that don't
apply.
So, I'd prefer to do this:
ConnectorGBean
- all connector code
- non-SSL config options
SSLConnectorGBean extends ConnectorGBean
- no additional connector code (config/mgmt only)
- always sets secure=true
- includes SSL config options (inherits non-SSL config options)
- ultimately can refer to an external keystore GBean
That wat if you go to manage a HTTP connector, it has only
settings pertinent to an HTTP connector, and if you go to manage an HTTPS
connector is has all the settings pertinent to an HTTPS connector.
Again, I'm not at all suggesting that we split up the code that
deals with the underlying Tomcat objects.
> If this is something you want to occur, then I would appreciate that
> this is opened up for discussion before anyone goes subclassing the
> ConnectorGBean.
Sorry -- I thought I wrote to the list about this aready, but it
was stuck in my postponed messages. Here was my original thought on the
topic.
Aaron
-------------------
So as part of this management API, I'd like to move a bunch of
properties out of the "initParams" and into separate properties for the
Tomcat connectors. Then those properties can be reflected in the
management interface.
One issue is that all connectors seem to support the same settings
-- in particular, the SSL settings, which I guess are just ignored unless
the secure flag is set. But it doesn't make sense to me to offer SSL
management properties for HTTP connectors.
That being the case, I'd like to break out an SSLConnectorGBean
from the ConnectorGBean. The SSL version would just extend the basic
one, add more manageable properties, and default the secure flag to true.
For now, you could still configure a SSL connector using the
standard ConectorGBean just to frustrate me, but eventually I'd like to
move all the connector properties into GBean properties and remove the
initParams all together.
> > On Wed, 27 Jul 2005, Matt Hogstrom wrote:
> >
> >>I was going to do that tonight or tomorrow and give Tomcat the same lovin.
> >>
> >>Matt
> >>
> >>
> >>----- Original Message -----
> >>From: "Aaron Mulder" <am...@alumni.princeton.edu>
> >>To: <de...@geronimo.apache.org>
> >>Sent: Wednesday, July 27, 2005 8:44 PM
> >>Subject: Jetty Max Threads Patch
> >>
> >>
> >>
> >>>Matt,
> >>>If you're up to it, can you submit an additional patch for the
> >>>Jetty connectors to fully implement
> >>>
> >>>
> >>
> >>modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
> >>tor.java
> >>
> >>>I've verified that the underlying product supports all the methods
> >>>in there (I put the URLs in the JavaDoc). There's also a
> >>>SecureConnector.java interface in the same dir for the SSL connector.
> >>>
> >>>Thanks,
> >>>Aaron
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
>
Re: Jetty Max Threads Patch
Posted by Jeff Genender <jg...@savoirtech.com>.
Aaron Mulder wrote:
> Tomcat will be a little more complicated because we have to break
> everything out of the initProps, and create a subclass for the SSL
> connector GBean, but it does support all the stuff we need, so it's mostly
> a matter of re-arranging.
For subclassing to make an SSL Gbean, I am against this...this nails up
a particular connector GBean, where what I have allows the connector to
be used for just that...a connector...any protocol, etc, makes no
difference here. The Connector architecture I have implemented allows
for a direct pass through to Tomcat's Connector object, and thus makes
it as flexible as possible.
If this is something you want to occur, then I would appreciate that
this is opened up for discussion before anyone goes subclassing the
ConnectorGBean.
>
> Thanks,
> Aaron
>
> On Wed, 27 Jul 2005, Matt Hogstrom wrote:
>
>>I was going to do that tonight or tomorrow and give Tomcat the same lovin.
>>
>>Matt
>>
>>
>>----- Original Message -----
>>From: "Aaron Mulder" <am...@alumni.princeton.edu>
>>To: <de...@geronimo.apache.org>
>>Sent: Wednesday, July 27, 2005 8:44 PM
>>Subject: Jetty Max Threads Patch
>>
>>
>>
>>>Matt,
>>>If you're up to it, can you submit an additional patch for the
>>>Jetty connectors to fully implement
>>>
>>>
>>
>>modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
>>tor.java
>>
>>>I've verified that the underlying product supports all the methods
>>>in there (I put the URLs in the JavaDoc). There's also a
>>>SecureConnector.java interface in the same dir for the SSL connector.
>>>
>>>Thanks,
>>>Aaron
>>>
>>>
>>>
>>
>>
>>
>>
>>
Re: Jetty Max Threads Patch
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Tomcat will be a little more complicated because we have to break
everything out of the initProps, and create a subclass for the SSL
connector GBean, but it does support all the stuff we need, so it's mostly
a matter of re-arranging.
Thanks,
Aaron
On Wed, 27 Jul 2005, Matt Hogstrom wrote:
> I was going to do that tonight or tomorrow and give Tomcat the same lovin.
>
> Matt
>
>
> ----- Original Message -----
> From: "Aaron Mulder" <am...@alumni.princeton.edu>
> To: <de...@geronimo.apache.org>
> Sent: Wednesday, July 27, 2005 8:44 PM
> Subject: Jetty Max Threads Patch
>
>
> > Matt,
> > If you're up to it, can you submit an additional patch for the
> > Jetty connectors to fully implement
> >
> >
> modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
> tor.java
> >
> > I've verified that the underlying product supports all the methods
> > in there (I put the URLs in the JavaDoc). There's also a
> > SecureConnector.java interface in the same dir for the SSL connector.
> >
> > Thanks,
> > Aaron
> >
> >
> >
>
>
>
>
>
Re: Jetty Max Threads Patch
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I was going to do that tonight or tomorrow and give Tomcat the same lovin.
Matt
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <de...@geronimo.apache.org>
Sent: Wednesday, July 27, 2005 8:44 PM
Subject: Jetty Max Threads Patch
> Matt,
> If you're up to it, can you submit an additional patch for the
> Jetty connectors to fully implement
>
>
modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
tor.java
>
> I've verified that the underlying product supports all the methods
> in there (I put the URLs in the JavaDoc). There's also a
> SecureConnector.java interface in the same dir for the SSL connector.
>
> Thanks,
> Aaron
>
>
>