On 08/12/17 19:29, Jesse Schulman wrote:
> Got it, that works and I was able to accomplish exactly what I needed,
> thank you!
> 
> One side note, the name ended up being:
> "Tomcat:name=\"https-jsse-nio-8443\",type=ThreadPool"
> 
> Which is a different order than your example so I am using the
> ObjectName(String domain, Hashtable<String,String> table) constructor so
> that I don't depend on order.
> 
> I was a little concerned that the name value had quotes in the string while
> the type value did not, meaning the name value has to be
> "\"https-jsse-nio-8443\"" while the type is just "ThreadPool".  Is this
> expected and should I keep an eye out for that possibly changing in a
> future version?

Yes the quotes are expected. It is to protect against unusual characters
appearing in the connector name.

It should not change between point releases and is unlikely to change
between major releases.

Mark


> 
> Thanks again for your help!
> Jesse
> 
> 
> On Thu, Dec 7, 2017 at 5:43 AM Mark Thomas <ma...@apache.org> wrote:
> 
>> On 06/12/17 18:32, Jesse Schulman wrote:
>>> For some reason there are no Catalina names from that MBean server:
>>>
>>> Registry.getRegistry(null, null).getMBeanServer().getDomains()
>>>
>>> yields
>>>
>>> JMImplementation, java.util.logging, java.lang, Tomcat,
>> com.sun.management,
>>> null, java.nio
>>>
>>> and
>>>
>>> Registry.getRegistry(null, null).getMBeanServer().queryMBeans(new
>>> ObjectName("Catalina:*"), null)
>>>
>>> yields an empty set
>>>
>>> Maybe there is something I need to do to enable JMX for the Catalina
>>> domain?  I didn't do anything to enable it for Tomcat but that domain
>> seems
>>> to show up already.
>>
>> The engine name is used as the MBean domain. For embedded, the engine
>> name is "Tomcat" rather than "Catalina" so you'll want modify the MBean
>> appropriately.
>>
>>> Also, if I can get access to the Endpoint MBean will I be able to get
>>> access to the Endpoint instance to call those two new public methods to
>>> pass my SSLHostConfig to the add method?
>>
>> No. You call the operations on the MBean and it takes care of the rest.
>>
>> Mark
>>
>>
>>>
>>> Thanks!
>>> Jesse
>>>
>>>
>>> On Wed, Dec 6, 2017 at 1:41 AM Mark Thomas <ma...@apache.org> wrote:
>>>
>>>> On 06/12/17 00:17, Jesse Schulman wrote:
>>>>> Now that 8.5.24 is released with new support for runtime
>>>> SNI/SSLHostConfig
>>>>> changes (thank you Mark!) I am trying to access the AbstractEndpoint
>> from
>>>>> our application to call these 2 new methods:
>>>>>
>>>>>     public void addSslHostConfig(SSLHostConfig sslHostConfig, boolean
>>>>> replace)
>>>>>
>>>>>     public SSLHostConfig removeSslHostConfig(String hostName)
>>>>>
>>>>> We have an instance of the Tomcat class from which we can do
>>>>> getConnector(), and that Connector can provide us with the
>>>>> ProtocolHandler.  With ProtocolHandler we could safely cast to
>>>>> AbstractProtocol but from there the getEndpoint method is protected.
>>>>>
>>>>> Is there a supported way to access the AbstractEndpoint via public
>>>> methods
>>>>> if I only have the Tomcat/Connector instances available?
>>>>>
>>>>> Or maybe this is possible to do with JMX?  If so I would need access to
>>>> the
>>>>> AbstractEndpoint directly so I can pass it my SSLHostConfig objects.
>>>>
>>>> The MBean for an Endpoint has a name that looks like this:
>>>>
>>>> Catalina:type=ThreadPool,name="http-nio-8080"
>>>>
>>>> The name part is the same as that shown in the logs. So if you see this:
>>>>
>>>> 06-Dec-2017 09:39:36.986 INFO [main]
>>>> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
>>>> ["https-jsse-nio-8443"]
>>>>
>>>> then the MBean name will be:
>>>>
>>>> Catalina:type=ThreadPool,name="https-jsse-nio-8443"
>>>>
>>>> The MBean server should be obtainable with:
>>>> Registry.getRegistry(null, null).getMBeanServer();
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to