I am working in a java project which implements MBeans and my need is to intercept MBean and change/add their properties before registry. Example :
domainName:name=myMBean --> domainName:name=myMBean1,type=myType
I found this link which presents how to apply an interceptor other then default interceptor but I have no idea to how do that in code.
Thanks in advance.
Once you register the bean obviously it is too late. The easiest thing to do is to change how the registration is done. If you show us what framework you are using to register the bean then I'll be able to help more.
Typically whatever is doing the actual registration is doing something like:
private MBeanServer mbeanServer;
...
mbeanServer.registerMBean(mbean, objectName);
You can therefore provide a different ObjectName:
ObjectName objectName = new ObjectName("domainName:name=myMBean1,type=myType");
But I assume you are not doing the registration yourself.
As an aside, I'm not sure you can switch to use a different JMX framework but I've put the finishing touches on my Simple JMX system recently. It allows objects to name themselves programmatically when they are published.
Related
Currently I'm using ComponentRenderers in my Vaadin application, but I would like to change it to LitRenderer (for better performance).
I read the documentation and I'm not sure about the "Note". Does it mean that the whole Person bean is exposed to the client, or only the Address bean from the example? I'm asking because I would like to use it for User bean which contains passwords...
https://vaadin.com/docs/latest/components/grid/flow#using-lit-renderers
As stated in the notes you have screenshoted. Only / all properties of the address is send to the client. If you would supply the user instance, the whole user instance' properties would be available in the client.
I have read the links
Akka and spring configuration
http://doc.akka.io/docs/akka/2.4.1/java/untyped-actors.html
Spring is no longer available as a module in Akka 2.4.1 but can be created and used as an extension. I also understand that the concept of bean/actor creation being managed by DI-fwk like Spring can cause fundamental conflicts with the Akka Actor parent-child/supervision model. So I still don't understand how to wire these together.
I have a set of actor classes and I have written them to be generic enough for example: properties like "listener", "name", "messageQueueName" etc are configurable. The link above tells me that I provide convenience factory constructors and then create actor with the code snippet
system.actorOf(DemoActor.props(42), "demo");
It is this line that I do not like. What I want to write in my application.conf is something like
deployment {
/demo {
magicNumber : 42
}
}
and then in all my application I simply want to look up the actor (I am okay to use the actorSelection) method.
Am I doing something wrong?
I think you are on the wrong path there, you should have a look at these tutorials:
http://www.lightbend.com/activator/template/akka-java-spring
https://myshittycode.com/2015/08/26/akka-spring-integration/
and for passing arguments via constructors check my answer to this question:
Custom Spring Bean Parameters
The configuration file is used for akka specific parameters (like specifying the dispatcher, mailbox, etc.)
I would like to delete some temporal files when user session finishes. The information associated with the files is stored in an object annotated with #SessionAttributes.
The only way I've found to deal with this is creating an HttpSessionListener.
Is there a higher level, simplified, Springy way to listen to the session end event where I could easily get my annotated object?
You most likely will need to create a HttpSessionListener.
Another stackoverflow answer:
Detect session timeout in Spring 3/Spring Security 2.0.5
Also and example on how to load spring beans into it:
http://www.mkyong.com/spring/spring-how-to-do-dependency-injection-in-your-session-listener/
Two options to use HttpSessionListener with spring beans:
The first is to use WebApplicationContextUtils.getRequiredApplicationContext(servletContext) to obtain the servlet context. From there you have two sub-options:
use getBean(..)
If you want to use #Autowired / #Inject use getAutowireCapablyBeanFactory().autowireBean(this). You will have to do this only once (check if the fields are null), because the listener is singleton.
The second option is to use AspectJ and #Configurable on the listener.
Not directly related, but might be an interesting project to look at.
https://github.com/shawnmclean/Idle.js
Session deletion typically happens on the server side, when the session expires (usually 30mn). The project above allows to detect user behaviors in the front end.
I'm using the platform MBeans server in Java 1.6, running in an OSGi container.
Using the MBeans for statistic counters and events mainly. The implementation of them are in one bundle, but they're instantiated in several other bundles. Every MBean autoregisters itself with the platform MBean server.
The problem is that when I attach via JMX and query for MBeans, I only get the ones that are currently registered, and they wont be registered until they've been instantiated (either because static classes don't exist until first access, or because the bundle hasn't started yet, or the counter is deep in some logic that wont exist until first use)
I need some way of subscribing to "register" events in the MBeans server. Or some other way of determining when there are new MBeans added to the server. Detecting removed MBeans would be an added bonus, but not necessary.
The only solution I've got is basically a thread that polls the server every 5 seconds and compares the result with a saved list of MBeans, and that is quite ugly.
All compliant MBeanServers will notify listeners of MBean registration and unregistration events. The key is to register a notification listener on the MBeanServerDelegate.
For example, a javax.management.NotificationListener implementation:
public class MBeanEventListener implements NotificationListener {
public void handleNotification(Notification notification, Object handback) {
MBeanServerNotification mbs = (MBeanServerNotification) notification;
if(MBeanServerNotification.REGISTRATION_NOTIFICATION.equals(mbs.getType())) {
log("MBean Registered [" + mbs.getMBeanName() + "]");
} else if(MBeanServerNotification.UNREGISTRATION_NOTIFICATION.equals(mbs.getType())) {
log("MBean Unregistered [" + mbs.getMBeanName() + "]");
}
}
}
To register the listener, add the notification listener against the MBeanServerDelegate. You can use an MBeanServerNotificationFilter if you want to filter which MBeans you are actually notified about. In this example, the filter is enabled for all ObjectNames.
// Get a reference to the target MBeanServer
MBeanServerConnection server = ManagementFactory.getPlatformMBeanServer();
MBeanServerNotificationFilter filter = new MBeanServerNotificationFilter();
filter.enableAllObjectNames();
server.addNotificationListener(MBeanServerDelegate.DELEGATE_NAME, new MBeanEventListener(), filter, null);
Your listener implementation will get a callback every time an MBean is registered or unregistered.
This sounds like you'd like to see all MBeans which exist anywhere but you can't since the code doesn't create all of them at once.
I suggest to use a code generator which creates "view" MBeans for all real MBeans. For example use a class or a marker interface to locate MBeans. The view beans should all be created on startup.
Now when the real MBean comes around, it should look up to its view and hook itself up.
That way, all MBeans will always be visible, startup won't suffer much (since the view MBeans will be really cheap) and the view MBeans can tell you the state of the real MBeans.
[EDIT] If you really only need to know when a new MBean is registered, extend an existing MBeanServer and override registerMBean(Object, ObjectName). Install the new MBeanServer by setting the System property javax.management.builder.initial.
Now define an MBean which exposes this information.
What's the recommended approach to intercepting session.getAttribute() and session.setAttribute()? This is in a Spring based application so something AOP-based would be great. I'd like to avoid having to override core Tomcat classes if possible.
Update: I want to store the actual serialized attributes in a web service.
I am not familiar with AOP or Spring (or Tomcat). :) But I am familliar with Java
The way I do it is set up a filter, and replace the request variable with my own object
request = new MyRequest(request);
Then override getSession() and getSession(boolean) to return an instance of MySession
the javax.servlet.HttpServletRequest and javax.servlet.HttpSession classes are Java EE standard and not Tomcat specific.
You could implement your own session org.apache.catalina.Manager and swap it into Tomcat's configuration, although the interface looks rather lengthy - so perhaps look at extending ManagerBase or StandardManager first.
As an alternative, register a HttpSessionAttributeListener to be notified whenever a session attribute is added/removed/updated. This won't change the default storage mechanism - the session data will still be kept in-memory as well - but it would let you persist the data with an alternative mechanism as well.