The behaviour with the jar is normal, however, you cannot deploy .mlet files! In JBoss terms, you would need an MLET SubDeployer which doesn't exist currently (unless you want to write it), or you could deploy the mlet programmatically, by writing an application that uses the standard JMX API.
But why you want to do this? It's very easy to just write an -service.xml descriptor that does the same with the MLET descriptor (and much more).
The reason I want standard MLET descriptor is that I want to be able
to drop the same jar with MBeans onto JBoss Weblogic and Websphere
Using JBoss service binds me to the JBoss API, which I can not do in my case., besides MLET is a standard thing that is defined by Sun's JMX spec..
If JBoss is JMX copliant why then this basic service is not there?
There is no spec defined mechanism for hot deployment of mlet files. This requires a programtic deployment using the standard jmx interfaces. This causes a chicken and egg problem as you need an app server specific startup mechanism.
I'm not sure what you mean by this?
I do use pure JMX API to load my beans,
something similar to JBoss's service config,
only mine also supports JMS relations and more.
I wanted to use MLET config to load my bootstrap bean, assuming that since MLET config is really a JMX spec thing it would then be supported by all JMX compliant app servers.
Our deployers don't know what to do with a ps-jmx-service.mlet file since the jmx spec says nothing about how such a file should be loadable into a jmx server. You have to have a piece of code that registers the mlet via an MLET, which requires a piece of code to create the MLET, which requires a jboss startup service. So you need jboss to add an mlet deployer. Create an RFE on sourceforge.
I understand now, the Sun's spec doesn't specify file naming convention for MLET and where it should be expected..
So, most likely Bea won't do it either.