Community
Participate
Working Groups
The load-time weaving system has a number of configuration parameters and a number of interesting statistics about its performance that it stores. It would be useful to provide a JMX interface to access and control these, even to generate warnings. I don't think this is a high priority when compared to correctness and optimizations but it's worth keeping in mind.
I think a JMX interface would be an excellent addition. We could certainly publish the same information that is issued in verbose messages such as class loader, list of configurations, options applied and list of aspects. We could even publish any messages including warning/errors although we need to make sure we don't hang on to too much information and increase footprint. Tracking statistics would also be very useful such as # classes woven, # types resolved etc. >It would >be useful to provide a JMX interface to access and control these, even to >generate warnings. I don't quite understand this though. Changing the configuration as supplied on disk will complicate things. What kind of warnings would you want a JMX interface to issue? Something we could certainly manage at runtime would be settings for problem diagnonsis such as trace and dump.
It's certainly true that having a JMX interface to change parameters makes it highly desirable to be able to persist those changes. To do this would probably require a separate aop.xml configuration file that is owned by JMX. But it would also raise the question of whether and how one can override aop.xml settings (which is itself becoming an interesting question, e.g., with Spring 2.0 RC's having <exclude within="org.springframework..*"/> in their aop.xml file). With respect to warnings, I was thinking that JMX alerts could be a useful way of identifying problems encountered by the load-time weaving system (e.g., it could be another message handler). I definitely agree that we need to limit retained output (especially verbose output) to not leak memory.
Most aop.xml files belong to the applications that use them or the aspect libraries that publish them. I’m not sure that changing them remotely, even if they could be modified on disk, makes any sense. If there is an uber-aop.xml file, that perhaps globally defines a message handler or Xlint for example, then it should be managed using the management infrastructure of the server platform. Yes, it would be a good idea to publish warnings and error through the JMX notification process but I don’t want to duplicate the function of the existing message handler or tracing infrastructure. For example by using java.util.logging in the weaver you should be able to control what is traced through jconsole. I’m not sure what to do about informational messages. My preference would be a platform-specific message handler and policy i.e. –verbose or whatever which integrated output with the server. That way if the whole server is managed remotely the user would see the big picture in one place. I have started playing with this including abstracting the JVM interface so that AspectJ can be managed on pre-Java 5 platforms. I will start with registering adaptors, weavers and worlds and giving access to interesting properties. I think just being able to see what’s going on will be quite helpful.
I'd find it very useful to have access to data about time spent weaving (in the preprocess method) on this thread. Time spent weaving by loader and overall would also be interesting data for many users, I'd think. Also, I agree that changing application aop.xml files wouldn't be a good thing. But allowing the JMX system to configure system defaults might be. It *would* be nice to allow plugging in some kind of persistent configuration mechanism that could be managed through JMX but that's a much bigger topic that would need to be designed. I'd vote for deferring that until we've done a lot more to tune and limit overhead for LTW. The parts of LTW that should be manageable in this way would include weaver options and settings especially configuration parameters (cache sizes, etc.).
>I'd find it very useful to have access to data about time spent weaving (in >the preprocess method) on this thread. Time spent weaving by loader and >overall would also be interesting data for many users, I'd think. Please take a look at the new tracing infrastructure, especially the default implementation. Each trace record has a millisecond timestamp that could be used by an offline tool to determine total time spent.
Having trace data with detailed timings is clearly valuable. It's surely also possible for me to plug in a trace listener that just tallies times to get this data. But it is pretty common to also offer JMX data with totals like total time weaving. In my case I'd benefit from online data that can report total time in weaving: Glassbox users have asked us to distinguish overhead time (mostly weaving) from time in underlying code. Glassbox is inherently an online tool. But I suspect a lot of users would find total times used in weaving interesting without having to add up times in trace records.
Initial feasibility work done. Need to decide what to expose. Need to test with non-Java 5 implementation.
unsetting the target field which is currently set for something already released
