System plugin causes register dump/panic

Submitted by markhale on Tue, 11/30/2004 - 20:23.

JNode-Core

I have written a system plugin, which uses the context classloader to load a class. When I boot JNode, the plugin causes a register dump:
abstract method ....... int_die_halt

(sorry, copy of dump unavailable)

If I replace the dynamic classloading with the new operator, then everything boots fine. So, are there any restrictions on what system plugins can do? Or is such a register dump unexpected?

System plugins

Submitted by admin on Wed, 12/01/2004 - 06:56.

You should be very carefull with system plugins, since they are at the core of the os.

What is this plugin about and why must it be a system plugin?

Ewout

JMX-microkernel plugin

Submitted by markhale on Wed, 12/01/2004 - 17:44.

I've been working on a management microkernel plugin. Specifically, a JMX implementation (so just a bunch of jars from a provider), plus a platform MBean server (a Plugin subclass creates an instance and binds it to InitialNaming, and there is an extension point so that other plugins can register MBeans in the platform server, e.g. the Log4J MBeans).

The problem crops up when trying to create an MBeanServer object. If I use the API way, then some dynamic classloading occurs as per spec. which seems to lead to the panic. If instead I use the provider API to avoid classloading, then it works fine. Java 5 compliance requires the standard API has to be used. One solution would be to make a few tweaks to the provider implementation.

Is there a (rough) list anywhere of what a system plugin can't do?

system plugins

Submitted by admin on Wed, 12/01/2004 - 18:31.

There is no list with what system plugins can & can't do. In principle it is the same as all plugins, except that it is treated differently by the classloader (loaded by the system classloader instead of a pluginclassloader).

Anyway, i see no reason for this plugin to be a system plugin. As long as it is in the initjar, it is always loaded.

Ewout

Why i made it system plugin

Submitted by markhale on Wed, 12/01/2004 - 18:58.

My choice of system plugin was to put it on the same footing as GNU classpath, since at some time in the future there will ba a java.lang.management package (Java 5) which will need access to this plugin. I'm also assuming that other system plugins will want to register MBeans, e.g. a VM MBean, driver MBeans. Let me also check, system plugins do have all permissions, right? So, if I set the context classloader to the system classloader, things might work??