[
https://issues.apache.org/jira/browse/TOMEE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136682#comment-17136682
]
Frans edited comment on TOMEE-2294 at 6/16/20, 2:14 PM:
--------------------------------------------------------
Just tried it again to confirm that I am not going crazy and the TomEE version
I'm working in is actually 7.1.3. It definitely is
Here it is with the system property commented out:
{code:java}
16-Jun-2020 22:17:22.916 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.startEjbs Started
Ejb(deployment-id=X, ejb-name=X, container=MessageDrivenContainer)
16-Jun-2020 22:17:22.919 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.createApplication Deployed
Application(path=C:localserver\webapps\ROOT)
16-Jun-2020 22:17:22.951 WARNING [JmsResourceAdapter-worker- - 2]
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits Memory
Usage for the Broker (1024mb) is more than the maximum available for the JVM:
981 mb - resetting to 70% of maximum available: 687 mb
16-Jun-2020 22:17:22.963 INFO [JmsResourceAdapter-worker- - 2]
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using
Persistence Adapter:
KahaDBPersistenceAdapter[C:localserver\conf\activemq-data\broker\KahaDB]
16-Jun-2020 22:17:22.979 INFO [JMX connector]
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can connect
to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
16-Jun-2020 22:17:23.003 INFO [JmsResourceAdapter-worker- - 2]
org.apache.activemq.store.kahadb.MessageDatabase$Metadata.read KahaDB is
version 6{code}
Uncommenting the property, the issue went away again.
{code:java}
16-Jun-2020 22:19:27.312 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.startEjbs Started
Ejb(deployment-id=X, ejb-name=X, container=MessageDrivenContainer)
16-Jun-2020 22:19:27.314 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.createApplication Deployed
Application(path=C:\localserver\webapps\ROOT)
16-Jun-2020 22:19:27.350 WARNING [JmsResourceAdapter-worker- - 1]
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits Memory
Usage for the Broker (1024mb) is more than the maximum available for the JVM:
981 mb - resetting to 70% of maximum available: 687 mb
16-Jun-2020 22:19:27.359 INFO [JmsResourceAdapter-worker- - 1]
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using
Persistence Adapter:
KahaDBPersistenceAdapter[C:\localserver\conf\activemq-data\broker\KahaDB]
16-Jun-2020 22:19:27.400 INFO [JmsResourceAdapter-worker- - 1]
org.apache.activemq.store.kahadb.MessageDatabase$Metadata.read KahaDB is
version 6{code}
Setting the log level to FINEST and searching for that INFO text shows that
createConnector is first called just after
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits
Decompiling that class and following back the references to cMSUL shows that
the isUseJmx() property is checked just afterwards. I'm guessing this isn't set
by ?useJmx=
{code:java}
@Override
public void start() throws Exception {
if (stopped.get() || !started.compareAndSet(false, true)) {
// lets just ignore redundant start() calls
// as its way too easy to not be completely sure if start() has been
// called or not with the gazillion of different configuration
// mechanisms
// throw new IllegalStateException("Already started.");
return;
}
setStartException(null);
stopping.set(false);
preShutdownHooksInvoked.set(false);
startDate = new Date();
MDC.put("activemq.broker", brokerName);
try {
checkMemorySystemUsageLimits();
if (systemExitOnShutdown && useShutdownHook) {
throw new ConfigurationException("'useShutdownHook' property cannot be be used
with 'systemExitOnShutdown', please turn it off (useShutdownHook=false)");
}
processHelperProperties();
if (isUseJmx()) {
// need to remove MDC during starting JMX, as that would otherwise causes
leaks, as spawned threads inheirt the MDC and
// we cannot cleanup clear that during shutdown of the broker.
MDC.remove("activemq.broker");
try {
startManagementContext();
for (NetworkConnector connector : getNetworkConnectors()) {
registerNetworkConnectorMBean(connector);
}
} finally {
MDC.put("activemq.broker", brokerName);
}
}
// in jvm master slave, lets not publish over existing broker till we get the
lock
final BrokerRegistry brokerRegistry = BrokerRegistry.getInstance();
if (brokerRegistry.lookup(getBrokerName()) == null) {
brokerRegistry.bind(getBrokerName(), BrokerService.this);
}
startPersistenceAdapter(startAsync);
startBroker(startAsync);
brokerRegistry.bind(getBrokerName(), BrokerService.this);
} catch (Exception e) {
LOG.error("Failed to start Apache ActiveMQ ({}, {})", getBrokerName(),
brokerId, e);
try {
if (!stopped.get()) {
stop();
}
} catch (Exception ex) {
LOG.warn("Failed to stop broker after failure in start. This exception will be
ignored.", ex);
}
throw e;
} finally {
MDC.remove("activemq.broker");
}
}
{code}
Then again, you probably wouldn't want an unauthenticated JMX port hanging
around outside of testing anyway, so the fix to just get rid of it isn't
unreasonable.
startManagementContext() calls ManagementContext.start(), which brings us back
to startConnector()
Looking at the commit to ActiveMQ5Factory, I'm seeing this line of logging
{code:java}
Logger.getInstance(LogCategory.OPENEJB_STARTUP,
ActiveMQ5Factory.class).getChildLogger("service").info("ActiveMQ5Factory
creating broker");
{code}
So, searching for 1099|ActiveMQ5Factory in the startup logs I get
{code:java}
78 16-Jun-2020 23:56:54.728 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker
ActiveMQ5Factory creating broker
80 16-Jun-2020 23:56:55.018 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker Using
ActiveMQ startup timeout of 10000ms
81 16-Jun-2020 23:56:55.019 INFO [ActiveMQFactory start and checkpoint]
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting ActiveMQ
BrokerService
89 16-Jun-2020 23:56:55.184 INFO [ActiveMQFactory start and checkpoint]
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting ActiveMQ
checkpoint
90 16-Jun-2020 23:56:55.184 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker ActiveMQ
broker started
205 16-Jun-2020 23:56:57.592 INFO [JMX connector]
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can connect
to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
{code}
The log line for broker started is definitely after setCreateConnector(false)
in GitHub
Decompiling org.apache.openejb.resource.activemq.AActiveMQ5Factory.class in
openejb-core.jar from my compile time references shows the code present
{code:java}
final ManagementContext managementContext = new ManagementContext();
managementContext.setCreateConnector(false);
broker.setManagementContext(managementContext);
{code}
Decompiling the same class from my tomee install's lib/openejb-core-7.1.3.jar
similarly shows it present
{code:java}
/* 189 */ ManagementContext managementContext = new ManagementContext();
/* 190 */ managementContext.setCreateConnector(false);
/* 191 */ broker.setManagementContext(managementContext);
{code}
Might be time to go to call it a night and try again tomorrow.
Thank you so much for all your help, and for maintaining this wonderful
framework. I really don't know what I'd do without it. You guys are brilliant.
Cheers,
Frans
was (Author: henskens):
Just tried it again to confirm that I am not going crazy and the TomEE version
I'm working in is actually 7.1.3. It definitely is
Here it is with the system property commented out:
{code:java}
16-Jun-2020 22:17:22.916 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.startEjbs Started
Ejb(deployment-id=X, ejb-name=X, container=MessageDrivenContainer)
16-Jun-2020 22:17:22.919 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.createApplication Deployed
Application(path=C:localserver\webapps\ROOT)
16-Jun-2020 22:17:22.951 WARNING [JmsResourceAdapter-worker- - 2]
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits Memory
Usage for the Broker (1024mb) is more than the maximum available for the JVM:
981 mb - resetting to 70% of maximum available: 687 mb
16-Jun-2020 22:17:22.963 INFO [JmsResourceAdapter-worker- - 2]
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using
Persistence Adapter:
KahaDBPersistenceAdapter[C:localserver\conf\activemq-data\broker\KahaDB]
16-Jun-2020 22:17:22.979 INFO [JMX connector]
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can connect
to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
16-Jun-2020 22:17:23.003 INFO [JmsResourceAdapter-worker- - 2]
org.apache.activemq.store.kahadb.MessageDatabase$Metadata.read KahaDB is
version 6{code}
Uncommenting the property, the issue went away again.
{code:java}
16-Jun-2020 22:19:27.312 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.startEjbs Started
Ejb(deployment-id=X, ejb-name=X, container=MessageDrivenContainer)
16-Jun-2020 22:19:27.314 INFO [localhost-startStop-1]
org.apache.openejb.assembler.classic.Assembler.createApplication Deployed
Application(path=C:\localserver\webapps\ROOT)
16-Jun-2020 22:19:27.350 WARNING [JmsResourceAdapter-worker- - 1]
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits Memory
Usage for the Broker (1024mb) is more than the maximum available for the JVM:
981 mb - resetting to 70% of maximum available: 687 mb
16-Jun-2020 22:19:27.359 INFO [JmsResourceAdapter-worker- - 1]
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter Using
Persistence Adapter:
KahaDBPersistenceAdapter[C:\localserver\conf\activemq-data\broker\KahaDB]
16-Jun-2020 22:19:27.400 INFO [JmsResourceAdapter-worker- - 1]
org.apache.activemq.store.kahadb.MessageDatabase$Metadata.read KahaDB is
version 6{code}
Setting the log level to FINEST and searching for that INFO text shows that
createConnector is first called just after
org.apache.activemq.broker.BrokerService.checkMemorySystemUsageLimits
Decompiling that class and following back the references to cMSUL shows that
the isUseJmx() property is checked just afterwards. I'm guessing this isn't set
by ?useJmx=
{code:java}
@Override
public void start() throws Exception {
if (stopped.get() || !started.compareAndSet(false, true)) {
// lets just ignore redundant start() calls
// as its way too easy to not be completely sure if start() has been
// called or not with the gazillion of different configuration
// mechanisms
// throw new IllegalStateException("Already started.");
return;
}
setStartException(null);
stopping.set(false);
preShutdownHooksInvoked.set(false);
startDate = new Date();
MDC.put("activemq.broker", brokerName);
try {
checkMemorySystemUsageLimits();
if (systemExitOnShutdown && useShutdownHook) {
throw new ConfigurationException("'useShutdownHook' property cannot be be used
with 'systemExitOnShutdown', please turn it off (useShutdownHook=false)");
}
processHelperProperties();
if (isUseJmx()) {
// need to remove MDC during starting JMX, as that would otherwise causes
leaks, as spawned threads inheirt the MDC and
// we cannot cleanup clear that during shutdown of the broker.
MDC.remove("activemq.broker");
try {
startManagementContext();
for (NetworkConnector connector : getNetworkConnectors()) {
registerNetworkConnectorMBean(connector);
}
} finally {
MDC.put("activemq.broker", brokerName);
}
}
// in jvm master slave, lets not publish over existing broker till we get the
lock
final BrokerRegistry brokerRegistry = BrokerRegistry.getInstance();
if (brokerRegistry.lookup(getBrokerName()) == null) {
brokerRegistry.bind(getBrokerName(), BrokerService.this);
}
startPersistenceAdapter(startAsync);
startBroker(startAsync);
brokerRegistry.bind(getBrokerName(), BrokerService.this);
} catch (Exception e) {
LOG.error("Failed to start Apache ActiveMQ ({}, {})", getBrokerName(),
brokerId, e);
try {
if (!stopped.get()) {
stop();
}
} catch (Exception ex) {
LOG.warn("Failed to stop broker after failure in start. This exception will be
ignored.", ex);
}
throw e;
} finally {
MDC.remove("activemq.broker");
}
}
{code}
startManagementContext() calls ManagementContext.start(), which brings us back
to startConnector()
Looking at the commit to ActiveMQ5Factory, I'm seeing this line of logging
{code:java}
Logger.getInstance(LogCategory.OPENEJB_STARTUP,
ActiveMQ5Factory.class).getChildLogger("service").info("ActiveMQ5Factory
creating broker");
{code}
So, searching for 1099|ActiveMQ5Factory in the startup logs I get
{code:java}
78 16-Jun-2020 23:56:54.728 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker
ActiveMQ5Factory creating broker
80 16-Jun-2020 23:56:55.018 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker Using
ActiveMQ startup timeout of 10000ms
81 16-Jun-2020 23:56:55.019 INFO [ActiveMQFactory start and checkpoint]
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting ActiveMQ
BrokerService
89 16-Jun-2020 23:56:55.184 INFO [ActiveMQFactory start and checkpoint]
org.apache.openejb.resource.activemq.ActiveMQ5Factory$1.run Starting ActiveMQ
checkpoint
90 16-Jun-2020 23:56:55.184 INFO [main]
org.apache.openejb.resource.activemq.ActiveMQ5Factory.createBroker ActiveMQ
broker started
205 16-Jun-2020 23:56:57.592 INFO [JMX connector]
org.apache.activemq.broker.jmx.ManagementContext$1.run JMX consoles can connect
to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
{code}
The log line for broker started is definitely after setCreateConnector(false)
in GitHub
Decompiling org.apache.openejb.resource.activemq.AActiveMQ5Factory.class in
openejb-core.jar from my compile time references shows the code present
{code:java}
final ManagementContext managementContext = new ManagementContext();
managementContext.setCreateConnector(false);
broker.setManagementContext(managementContext);
{code}
Decompiling the same class from my tomee install's lib/openejb-core-7.1.3.jar
similarly shows it present
{code:java}
/* 189 */ ManagementContext managementContext = new ManagementContext();
/* 190 */ managementContext.setCreateConnector(false);
/* 191 */ broker.setManagementContext(managementContext);
{code}
Might be time to go to call it a night and try again tomorrow.
Thank you so much for all your help, and for maintaining this wonderful
framework. I really don't know what I'd do without it. You guys are brilliant.
Cheers,
Frans
> Can't disable unauthenticated JMX on 1099
> -----------------------------------------
>
> Key: TOMEE-2294
> URL: https://issues.apache.org/jira/browse/TOMEE-2294
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Reporter: Frans
> Priority: Major
> Fix For: 8.0.3
>
>
> ActiveMQ comes bundled with a JMX host that is default on unauthenticated on
> port 1099.
> {code:java}
> <Resource id="JmsResourceAdapter" type="ActiveMQResourceAdapter">
> BrokerXmlConfig = broker:(vm://broker)?useJmx=false
> ServerUrl = vm://broker
> </Resource>{code}
> Tomee's resource configuration doesn't allow this to be disabled. The above
> doesn't work.
> This can be disabled by inspecting an activemq jar's manifest, pulling down
> the same version of activemq-all, and putting that in the tomee/lib
> directory, at which point this works:
> {code:java}
> <Resource id="JmsResourceAdapter" type="ActiveMQResourceAdapter">
> BrokerXmlConfig = xbean:file:activemq.xml
> ServerUrl = vm://broker
> </Resource>
> {code}
> {code:java}
> <broker xmlns="http://activemq.apache.org/schema/core";
> useJmx="false"
> brokerName="broker"
> useShutdownHook="false"
> persistent="true"
> start="true"
> schedulerSupport="false"
> enableStatistics="false"
> offlineDurableSubscriberTimeout="259200000"
> offlineDurableSubscriberTaskSchedule="3600000">
> {code}
> However, convincing the guy hosting the server to inspect JAR manifests, pull
> down specific jars, and maintain a second configuration file seems like a lot
> of effort to go to just to have the ability to disable unauthenticated access
> to every MBean in the VM
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
