[adrian.brock]

I have been thinking about this some more.
These should really just be annotations.

The JMX spec is moving that way.

In JMX1.3 descriptors are extended and supported on all MBean types:
http://jcp.org/aboutJava/communityprocess/maintenance/jsr003/jsr3-mr3-change-log-standalone.html#Descriptors
http://download.java.net/jdk6/doc/api/javax/management/Descriptor.html

In JMX2.0 these will all just be annotations anyway.

The JavaEE specs are moving to annotations for configuration as well.

The part that is missing is the meta-annotations, something we
cannot fix directly for the standard annotations, but this information
can be provided through a meta-annotation repository.

e.g. Take configuring a bind address/port.

// Pseudo code
public @interface BindAddress
{
@RealType("java.net.InetAddress")
String address() default "0.0.0.0";

@Minimum(0)
@Maximum(65535)
int port() default 0;
}

[adrian.brock]

but it really does not solve the problem of mapping a deployment bean's metadata to a meaningful view. Its probably an intractable problem from just the bean metadata level

I am not sure I understand this.
I think this goes back to the Policy vs Service view of things.

The JMX Console view is not useful (except for a super user).
The user is interested in setting the properties of the deployment,
e.g. the connection url of the datasource.

What is useful is presenting a notion of "DataSource deployment"
with its properties and make that controllable via a JSR88 style api.
Then provide feedback on that deployment via a JSR77 api,
like status or monitoring of stats, etc.

[adrian.brock]

I'm not discarding the POJO/MBean view.

One such deployment from above might be a basic POJO or MBean
deployment, but without the meta-annotations this is going to show very basic
information to the management layer.

[starksm64]

but it really does not solve the problem of mapping a deployment bean's metadata to a meaningful view. Its probably an intractable problem from just the bean metadata level

I am not sure I understand this.
I think this goes back to the Policy vs Service view of things.

The JMX Console view is not useful (except for a super user).
The user is interested in setting the properties of the deployment,
e.g. the connection url of the datasource.

What is useful is presenting a notion of "DataSource deployment"
with its properties and make that controllable via a JSR88 style api.
Then provide feedback on that deployment via a JSR77 api,
like status or monitoring of stats, etc.

Yes, this is all about the current lack of an admin/configuration view that pulls together the relevant settings from the various DataSource beans that make up a deployment into the relevant view more akin to the *-ds.xml settings.

[ccrouch]

U1) List the Deployments which are deployed in the Server
* How to get the name of the Profile which the Server is currently using, e.g. "default"?
Profile profile = ProfileService.getProfile("default")
Deployment[] deployments = profile.getDeployments()

Right.

But what about boot strapping? How do I find out which Profile the server is currently using?

[ccrouch]

Its not clear that this should be a manifest api in the ProfileService. Why wouldn't this be an implementation detail that picks up the transaction aspect when running in a context with a transaction (and ejb3 embedded implementation of the ProfileService)?

Ok, I guess the bigger question is how could any implementation of the Profile Service support transactions in any useful way. I could envisage treating Deployments as transactional resources just by storing them in a DB, but what about when it comes to updating Policies for Deployments which are running, e.g. how can I tell my JMS Server to rollback that change that I just made to it? Maybe this topic should be discussed on a subsequent thread?

[ccrouch]

Similarly, a Policy associated with a Deployment may not be meaningful to write to except when active in a server. A Policy is about wiring the Deployment bean values to container "beans".

I disagree. You should be able to update a Policy associated with an inactive Deployment. When the Deployment becomes active, e.g. server starts up, that Policy change should come into effect.

[ccrouch]

but it really does not solve the problem of mapping a deployment bean's metadata to a meaningful view. Its probably an intractable problem from just the bean metadata level, so it seems like we need a notion of a logical management view in between the profile service api and the management tools so that if I rewrite the jmx console using portlets, I don't need an intimate knowledge of the deployment beans to create simple portlets.

I don't believe we need another logical management view. Deployment Beans should be at the "right" granularity for users to deal with. If they are not then aren't they just serving as "proxies" to the low level services (ManagedConnectionPool, ManagedConnectionFactory) we are trying to abstract away from?

When you say "rewrite the jmx console" do you mean develop a UI which allows for deployments to dynamically come and go, and for policies to change overtime without requiring updates to the UI code? This is a good thing to strive for. I hope it is what you meant because I don't see the benefit of trying to revive a view into the container which had such a low signal-to-noise ratio because of the exposure of implementation details which most people didn't care about.

[ccrouch]

I have been thinking about this some more.
These should really just be annotations.

Ok, I'm obviously missing something. Won't we still need the whole PropertyInfo business so that clients of the ProfileService can see how a particular Deployment can be configured?

[ccrouch]

What is useful is presenting a notion of "DataSource deployment"
with its properties and make that controllable via a JSR88 style api.
Then provide feedback on that deployment via a JSR77 api,
like status or monitoring of stats, etc.

+1. A combination of JSR88 and JSR77 "style" apis is exactly what I believe the ProfileService is trying to define.

[adrian.brock]

I have been thinking about this some more.
These should really just be annotations.

Ok, I'm obviously missing something. Won't we still need the whole PropertyInfo business so that clients of the ProfileService can see how a particular Deployment can be configured?

Yes, in terms of what annotations are applicable.
I am using annotations in the generic JavaEE sense like you could have
either:

<resource-ref>
or
@ResourceRef

A complete xml schema for each deployment type would be good
way to define applicability and would serve as the "template thingy"?

[starksm64]

I don't believe we need another logical management view. Deployment Beans should be at the "right" granularity for users to deal with. If they are not then aren't they just serving as "proxies" to the low level services (ManagedConnectionPool, ManagedConnectionFactory) we are trying to abstract away from?

When you say "rewrite the jmx console" do you mean develop a UI which allows for deployments to dynamically come and go, and for policies to change overtime without requiring updates to the UI code? This is a good thing to strive for. I hope it is what you meant because I don't see the benefit of trying to revive a view into the container which had such a low signal-to-noise ratio because of the exposure of implementation details which most people didn't care about.

This is not correct. The deployment is an expression of what the MC has to deploy, just as jsr88 is the real contents to deploy. What we need is the equivalent of the jsr77 view which says what a given type of deployment looks like.

[starksm64]

Similarly, a Policy associated with a Deployment may not be meaningful to write to except when active in a server. A Policy is about wiring the Deployment bean values to container "beans".

I disagree. You should be able to update a Policy associated with an inactive Deployment. When the Deployment becomes active, e.g. server starts up, that Policy change should come into effect.

Yes, so tie it back to the quoted context. There were no lifecycle apis because the bootstrap function of the profile service is to provide the configuration information equivalent to all of the information available in a server default directory structure. Active management of a deployment including querying the state is a seperate function. How these tie together such that a profile can be updated with the possibility of persisting the change in the configured services is where we need to get to.

[starksm64]

U1) List the Deployments which are deployed in the Server
* How to get the name of the Profile which the Server is currently using, e.g. "default"?
Profile profile = ProfileService.getProfile("default")
Deployment[] deployments = profile.getDeployments()

Right.

But what about boot strapping? How do I find out which Profile the server is currently using?

The name of the profile the server is using is some configuration parameter on a bootstrap level component. Its not part of the profile service.

[starksm64]

A complete xml schema for each deployment type would be good
way to define applicability and would serve as the "template thingy"?

I don't see how this can be particulary useful as its a function of the deployment implementation. The most ill defined is a sar deployment which can have who knows what.