If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name.

The only scenario where I can see needing to specify a loader-repository is if a standalone bean deployment needs to use the scoped namespace of another legacy deployment. This is a rather exotic deployment for most users.

If your just talking about allowing a standalone bean deployment to use a scoped class loader, can't we just use a bean reference to a class loader configuration and embed the configuration in the target bean?

How is the type enabling the namespace management? In you example it would seem that you are carving out a Queue namespace that can be augmented with keys known to be unique in the Queue namespace. So you want a type based name to ObjectName mapping function on the alias aspect of the SARDeployer?

Yes, I would segment the namespace by type IF I were going to do it that way.

The trouble is that it relies on something that does not really exist, i.e.some notion of an abstract Queue MBean or class/grouping of such MBeans.

Such a notion could be retrofitted to the MBeans with agetAliasType()/getAliasName()but that is pretty intrusive to the implementationor it requires more xml in the deployment to state it,or it requires another listener on deployments to generate the alias databasefrom known patterns in MBean deployments (often with those patterns being conventionsonly).

So use both an explicit alias attribute on the legacy mbean for complete control, and allow for a mapping function on the SARDeployer to transform ObjectNames meeting understood patterns to be transformed into a unique alias. The latter should generally be universially applicable as one would expect a convention was in place for all object names.

Yes, but surely all that does is introduce a binding to the new alias notionrather than the ObjectName.

This might be useful for solving some problems like specifying the default datasource(which already has an alias in that DefaultDS is already "hardwired" is some places)

To solve some other problems you would need to be able to specify an aliasbased on some other name. e.g. automatically adding dependencies onresource-refs based on jndi-name or ejb-refs based on ejb-namei.e.

<depends type="ejb" name="MyEJB"/>
would resolve to
jboss.j2ee:service=EJB,jndiName=MyEJB
but this also depends upon context as well since MyEJB can exist in multiple
deployments.

I don't think adding a "trivial" alias notion would solve many problems, and it would likely confuse some users. Users are confused enough when the MBeans are created by deployers so they don't know what names to use.

Instead, we should be working towards defining an extensible dependency notion that understands context, type or anything else that might be important. This should produce something intuitive and allow users to "write their own dependency" if nothing fits what they need.

Ok, but we seem to be mixing legacy vs future naming issues. Just throwing an alias attribute onto the existing mbean would seem to ease integration of non-jmx based stuff into the jmx mc, and avoids the exposure of a jmx name dependency in the new bean deployer.

This can be done by introducing something that is based on what we wantgoing forward (even if it is incomplete).

e.g. when I've integration the jmx/pojo MCsthe injection should be "transparent" between the two. The transaction managerfactory above, doesn't really know that it is using an MBeanProxy on theTransactionManagerService.

The problem before that integration (jboss4) is that the lifecycles orconfiguration spaces aren't linked, except that the whole bean deployment ismanaged by an MBean known to the SARDeployer.

I can hack some things to make it work better, but it isn't going to work as wellas the real solution in JBoss5.There is sort of cross over here, in that we still want the old loader-repositoryconfig to work in JBoss5, even when the classloaders are part of the DI framework.

I don't know yet. If it was trivial, I probably wouldn't have mentioned the issue in the forums :-)

The issue is to spot that a dependency/injection is really an external dependency outside the control of the bean MC and preprocess them into "depends" to attach to the ServiceController registration, i.e. the wrapping container.

Anyway, we said we weren't going to worry too much about the JMX integration for JBoss4 (at least in the initial release).

Certainly, I could make it a rule that if the depends or inject tag in the bean's xmlhas a name that is a valid ObjectName, then it is assumed tobe a jmx dependency. This logic can be hidden away in the deployer/dependencyprocessing of JBoss4's BeanDeployer.

Whether we want to keep the jmx ObjectName as the namespace conventiondown the road is a different issue. It does have some advantages in termsof the flat namespace and querying, but it fails in its original intention of being a "logical"name for the underlying object (which is probably partly a fault of the way we use it).

In many ways, querying on the real attribute/property values is probably better?

Like I expressed above, I don't think that just a name is necessarily the best/only wayto do this. Though using any other scheme will still require at least an internal unique "id".

I think we are still on topic target, its just a question of how the bean deployer is implementing the depends tag. Maybe I'm confusing the issue with the belief that the bean deployer already has a depends tag. That is what I am thinking and the question is one of making the jmx mc components available as dependencies targets in the bean deployers.

As you said, this has a straightforward impl if one uses the jmx mc component object name, and the bean deployer assumes valid jmx names refer to components in the jmx mc.

Beyond that is the question of mapping the jmx mc names into a non-jmx object name namespace for more natural pojo mc naming convention. Its a notion that has validity purely in the jmx mc as well given that there are more logical names/aliases for many services.

For the not so logical names such as that assigned to an ejb local home or mdb deployment, there really is no natural name other than the existing ejb-name, but its far from being unique. I'm punting on this for now.