Use of JBAS5 management api's by user apps

[ccrouch]

Is it going to be theoretically/practically possible for user applications to make use of the same annotations currently being added to the Datasource/JMS components in AS5?

The idea here would be for a regular .war/.ear application to benefit from the profileservice/metadata repository functionality which is built into the app server.

For example, I have an app that runs a batch job every 60minutes, I would like to make this frequency configurable, but don't want to deal with making this configuration persistent and reading/updating it etc. Instead I just want to annotate that this property and its parent class with the appropriate ManagedProperty/ManagedObject/ManagedComponent annotations, so that I can query the profile service for a management interface, then set the new frequency value, and know that that new value is going to be set on my component when the app server restarts?

I guess this would be somewhat analogous to having user apps make use of the JMX server in JBAS4.x...

Thanks

[starksm64]

The integration point for the management interface is the deployer associated with the component with the annotations. As long as the deployer implements the ManagedObjectCreator interface, the component will be manageable. As long as the component property maps to a piece of metadata for the component deployment, its managable.

If your talking about non-spec defined metadata (not an env-entry, config parameters, etc.), then annotating would not have any effect.

[ccrouch]

So only spec defined metadata is managable for things like .wars and .ears because those are the only things the which the .war and .ear deployers knows about?

So if you wanted to add support for non-spec defined metadata you would need to write another deployer?

[starksm64]

So only spec defined metadata is managable for things like .wars and .ears because those are the only things the which the .war and .ear deployers knows about?

Yes. An aspect overrides the deployment metadata to incorporate the management changes.

So if you wanted to add support for non-spec defined metadata you would need to write another deployer?

That is not going to help as deployers run off of the deployment metadata attachments. If it was an mc bean property, or jmx mbean property that controlled the frequency, it would already be managable via the corresponding component deployer.

So, if you make your configuration object an mc mbean, and then inject it, you would have a managable configuration object. We should allow injection of mc beans into ee components via an @Resource(...) annotation.

Otherwise, you would have to replicate behavior the profile service/deployers perform for deployment metadata.

[ccrouch]

So, if you make your configuration object an mc mbean, and then inject it, you would have a managable configuration object. We should allow injection of mc beans into ee components via an @Resource(...) annotation.

Ok I gotya I think. So make your components mc beans and you're good to go from a ManagedProperty/ManagedObject/ManagedComponent perspective? So one would be able to query/update it as we do DS/JMS components today? The fact that that bean is then bundled up into a .war as part of your application wouldn't be relevant from a management perspective.

[starksm64]

Correct, other than we don't deploy mc beans from wars right now.

[ccrouch]

Correct, other than we don't deploy mc beans from wars right now.

Okay, great. That would be a bit of a problem :-). I guess until we do, one could use a more mc bean friendly deployment structure e.g. .sar? and then include the webapp in that.

[starksm64]

Sars are for the old jboss mbeans, so either that, or a myapp-config-beans.xml for mc beans in an ear or standalone is what is needed.

We should allow war to have a META-INF/myapp-config-beans.xml as well at some point.

[ccrouch]

Thanks Scott.

FWIW I added http://jira.jboss.com/jira/browse/JBAS-5271 to cover adding the .war support

[adrian.brock]

I closed it, read my comment.

[ccrouch]

And as if by magic, Adrian stirs...

"For a web-app, you put the -beans.xml in .... WEB-INF :-)
The same goes for any other metadata, e.g. the new jboss-classloading.xml"

[alesj]

"For a web-app, you put the -beans.xml in .... WEB-INF :-)

On the other hand I have people complaining that we're picking up too much :-)
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131021&postdays=0&postorder=asc&start=10

[adrian.brock]

Getting resources from WEB-INF instead of WEB-INF/classes
isn't defined in the spec. So its not portable for an application to put stuff there anyway.

The example shown, is just a conflict in metadata extensions between the MC
and the Spring deployer.
You'd get a similar problem if somebody wrote a deployer that asked for
".xml" extensions :-)

[alesj]

You'd get a similar problem if somebody wrote a deployer that asked for
".xml" extensions :-)

Sure, but he's asking for silent failover/ignore if dtd/schema doesn't match what deployer expects.
Something to discuss further (in a separate post of course, since already on a verge of hijacking this one :-))?