I have been asked to investigate feasibility of some projects. One of them requires registering and unregistering MBeans explicitly from TomEE's JMX Infrastructure (MBeanServer provided by OpenEJB, I believe).
Websphere provides an implementation for accessing its singleton MBeanServer using the code
AdminService.getMBeanFactory().getMBeanServer();
I was wondering if any such implementation exists in TomEE/Tomcat with OpenEJB. Any direction would be appreciated.
Yes LocalMBeanServer but this is fully useless if you don't want to be able to switch some MBeans off. TomEE keeps thing simple and just rely on JVM MBeanServer (ManagementFactory one)
Related
I am working on a Spring boot project which uses Hazelcast as Cache. I am using the community edition of that. I have couple of questions,
I wanted to know whether there is minimal provision provided in community edition for security features. I know that we can provide unique group name so other nodes cannot join the cluster. But is there any other way?.
I also tried with hazelcast.application.validation.token but it is not working. What is the correct way to check with this property.
Also, hazelcast communicating using TCP is not blocked by spring boot. Is there any way in spring security to add some security feature to hazelcast?
I suppose, you're using Hazelcast 4.0 or later. The property hazelcast.application.validation.token was removed in version 4.
Maybe you've already looked into this answer - it's related to Hazelcast 3.y versions. Some info is still valid though.
The basic protection approach in Hazelcast version 4 (OS) is to set different cluster names (equivalent of group name in Hazelcast 3).
You can use the advanced network feature which allows you to have separated port numbers for different protocols (member protocol, client protocol, REST, ...). Then you can use OS level protection - such as firewall - to protect these endpoints.
You can also disable binding server sockets to all network interfaces (default behavior) and control which interface is used.
I don't think the Spring security provides a feature which would help you with protecting Hazelcast endpoints, but I'm not Spring expert, so maybe I'm wrong.
I'm trying to configure IBM WebSphere Liberty server (16.0.0.3) so that one of our applications runs there, but, besides the obvious unreliability, the server takes just to much time to start.
This is clear on the log files:
[17-11-2016 15:54:16:231 GMT] 0000001c com.ibm.ws.webcontainer.security.ServletStartedListener I CWWKS9122I: For URL /* in application com.ibm.ws.jmx.connector.server.rest, the following HTTP methods are uncovered, and accessible: HEAD OPTIONS TRACE
[17-11-2016 15:56:18:349 GMT] 0000001b org.jboss.weld.Event I WELD-000411: Observer method [BackedAnnotatedMethod] public org.omnifaces.VetoAnnotatedTypeExtension.processAnnotatedType(#Observes ProcessAnnotatedType<T>) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
[17-11-2016 15:56:19:798 GMT] 0000001b com.ibm.ws.ejbcontainer.osgi.internal.EJBRuntimeImpl I CNTR4000I: The ALLPLEXEJBeans-v2.jar EJB module in the ECC application is starting.
As you can see, there are more than 2 minutes separating the first two lines, which is ridiculous, especially considering that it is a very small application.
What can I do to speed this up before giving up on Liberty profile?
CDI is a very useful, cross-cutting technology, but as part of that the CDI engine potentially needs to scan every single class in your application to see what is and isn't a CDI bean and to interpret other annotations, etc.
To improve Liberty startup time by limiting CDI scanning
Two approaches:
1. If you wish to use CDI in some applications, but not in others
Tell CDI to only scan applications that contain a beans.xml file. Disable "implicit" bean archives in Liberty by including this in your server config (server.xml)
<cdi12 enableImplicitBeanArchives="false"/>
See here for a bit more discussion.
2. If you don't wish to use CDI at all, remove the CDI feature from the server config.
As Brett Kail pointed out, if this is the only application in the server and/or you don't want or need CDI at all, you can remove the cdi-1.2 feature altogether from the <featureManager>. As he also pointed out, be aware of features like webProfile-7.0 or javaee-7.0 which include the cdi-1.2 feature.
I'll be developing stand-alone Java application being JMS client. I want to make sure that every time I send a message to a queue, I do not have to create session, connection etc.
I was thinking of using CachedConnectionFactory which comes with Apache Camel or using the solution Spring provides. Still, as far as I know the limitation of the former is that it is not suitable for transactions, and of the latter, that it may not behave correctly in case of failover.
On one post (http://stackoverflow.com/questions/8922339/how-to-pooling-the-jms-connection-in-a-standalone-java-applications) it was suggested to use Apache commons pool component, but I don't think creating such pool would be a trivial task anyway
Any comments on that?
I'm trying to implement dependency injection for a WCF service hosted in an Azure WebRole that runs in full-trust mode (So there are two separate processes).
I've tried Ninject so far and I had no problems injecting dependencies into the WCF service using the method described in this article: http://tinyurl.com/cnxrscg
However, I still have two unresolved issues:
I can't seem to find a way to instantiate the Kernel before RoleEntryPoint, so that I can inject the dependencies I need into it. Am I supposed to create it from there or is there a better practice?
Since running in full-trust means two processes, does this also mean I have no other choice but to create two separate Kernel instances?
Note: I'm not interested in a Ninject-specific solution. As a matter of fact, I've stumbled across many shortcomings while dealing with it so I'm considering a different IoC container. Which one works best with Azure?
Thanks!
Each AppDomain needs its own container. Sharing a container over AppDomains or even across processes is something that is typically not supported by a container, and if it is, it costs a lot of performance, since all the marshalling that will be going on between the two AppDomains. Besides, each AppDomain typically represents its own application, and each application often needs its unique registration. This by itself justifies giving each AppDomain its own container.
I have a Java app running on Tomcat, and I would like to monitor counters using Windows Performance Monitor. Is this possible using a JMX adapter for the Java MBeans or by some other means?
The following tutorial might be of use:
http://www.developer.com/java/ent/article.php/3087741/Hooking-to-PerfMon-from-Java.htm
It shows how a Java application defines a custom counter that can be monitored in Perfmon. It basically boils down to using an extension DLL to the performance monitor and communicating with that via a memory mapped file. You could then hook your JMX counters into a similar mechanism so that they can be monitored from Perfmon.
Since you tagged this with JMX and MBeans, I assume your counters are accessible from a Java MBean. If so you could use jconsole, provided with the Java SDK, to monitor the counters. Once you find your MBean in the MBeans tab, double click on the value and it will draw a nice line graph for easy monitoring.
See JConsole Guide for more info.
This seems to be exactly what you're looking for, but it's not free:
http://www.adventnet.com/products/snmpadaptor/faqs/general.html
If you want to do this programatically, you can create a JMXConnection to the machine, then accessing the MBeans from there. We did this ourselves for a function test that involved keeping track of the number of threads in the application, which there's a counter for that you can access through JMX. If you want nice graphs and things like that I suggest using JConsole, as mentioned above. There's also a program called JProfiler that works like JConsole on steroids, basically. There's a free trial so you can try it out.
This article outlines how to access Windows PerfMon stats from Java and expose them as MBean attributes through JMX.