ServiceMetaData has the most recent dependencies/attributes/

[anil.saldhana]

The ServiceMetaData dependencies/attributes/annotations just store the most recent ones. So for example, if I have a service bean at the EAR level, then I would need to create dynamic dependencies to the individual web,ejb components within the Ear. So deployers working with the war,ejb-jar deployments would want to create a dependency for these components on to the parent service bean (at the ear level for example). I would like the service bean at the ear level to start only after all the sub service beans in the ear have started.

I propose changes to be made such as:

/**
 * Set the dependencies.
 *
 * @param dependencies the dependencies.
 */
 public void setDependencies(List<ServiceDependencyMetaData> dependencies)
 {
 if (dependencies == null)
 throw new IllegalArgumentException("Null dependencies");
 if(this.dependencies.size() == 0)
 this.dependencies = dependencies;
 else
 this.dependencies.addAll(dependencies);
 }

[starksm64]

Then there is no way to clear out or explicitly set the dependencies list. There should just be add/remove methods to support extending the dependencies.

[anil.saldhana]

I was looking for something like addDependencies/addAttribute in the servicemetadata.

[starksm64]

Yes, let's add those.

[alesj]

I was looking for something like addDependencies/addAttribute in the servicemetadata.

I don't think you want to alter someone's metadata, if you cannot bring it back to original state as the user wanted.
See all the MC posts about cloning the metadata after changing it to get some inner anonymous bean behavior.

[starksm64]

If you have multiple deployers producing an aggregate metadata view the metadata will have to change. The 'users' view is a function of where you start at in the deployer chain. If I'm passing in authoritative metadata and expect 'metadata' deployers to be bypassed, that is something we would need better support for. Essentially an isMetaDataComplete(Class) call.

What's the bean example?

[starksm64]

Alternatively, we need to be making better use of the MetaDataRepository and scopes to create the layered views.

[alesj]

What's the bean example?

Could be a different issue, but I think it's all about reproducing user's request.
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=128236
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=105759
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89581

[starksm64]

Its a similar discussion, and I'm not sure what the clone of the ClassLoaderMetaData is acomplishing. In the thread about unwrapping the bean fro the classloader element to add it as a dependency to the BeanMetaData is essentially what we are talking about here. One piece of metadata is introducing another dependency. In this case, to ServiceMetaData rather than a BeanMetaData.

The real issue is having deployers separated such that if we are running with a profile service that can override the metadata for a deployment with that from an admin tool (the open console), we don't overwrite that metadata. I can still see modifications being made to this for things like dependencies that are internal deployer details. These should not be showing up in the console as dependencies.

[adrian.brock]

Its a similar discussion, and I'm not sure what the clone of the ClassLoaderMetaData is acomplishing.

It's not really the same thing.

EXPLANATION OF WHAT ALES IS TALKING ABOUT

In the BeanMetaData we play around with some things,

e.g. (using xml to illustrate)

<deployment>
 <classloader/>
 <bean1/>
 <bean2/>
</deployment>

effectively gets turned into

 <bean1>
 <classloader/>
 <bean1>
 <bean2>
 <classloader/>
 </bean2>
</deployment>

There's a similar issue where a nested bean gets replaced with an inject:

 <bean>
 <property><bean name="A"/></property>
 </bean>

becomes

 <bean name="A"/>
 <bean>
 <property><inject bean="A"/></property>
 </bean>

These changes end up being irreversable and so we don't really keep
what the user requested. They can't undeploy/modify/redeploy
because the metadata has changed in ways they probably didn't expect.

The ServiceMetaData doesn't really have the same problem
(although it might if we expand its features to be more like the POJO stuff).

SERVICEMETADATA AS IMPLEMENTATION DETAIL

What this thread is about is whether it is ok to modify the service metadata
created by other deployers to add dependencies.

This metadata is implementation detail and not seen by the user
who deals with the ejb or web metadata.

The obvious question is whether this use case is really an implementation detail
or something the user should manage.

If it is something the user should control (e.g. see the default clustering dependencies
deployer),
then the dependencies need adding to the ejb/web metadata along other explicit
dependencies from jboss{-web}.xml

If it is just an implementation that may change in the future then it is probably
better modifying the "hidden" ServiceMetaData.

TRANSITIVE DEPENDENCIES

In practice, this just shows that the EJB/WEB containers are not
creating their containers correctly and the respective service being
used is not exposed for IOC (or aspect dependency) properly.

If they were these kind of transitive dependencies;
ejb -> security -> security policy
ejb -> security aspect -> security policy injection into the aspect
would be would be automatic.

AFTERWORD

I've deliberately refrained from analysing/commenting on the
security deployers/integration (until now)
since they are fundamental wrong/broken
and need a complete rewrite which we don't have time to do before JBoss5. ;-(

I may find time to fix some bits when I sort out the ejb deployers,
e.g. one obvious one I saw somewhere was checking if it was an ejb/war
by looking for META-INF/ejb-jar.xml or WEB-INF/web.xml.

* These files aren't even mandatory anymore (annotations or programmatic deployment)

* Somebody could in principle turn another type of deployment into a war
by adding Web metadata to the attachments, e.g. exposing an ejb as a webservice
That's the whole point of the aspectised deployments.

There a few other brain deaths in there (which I saw in passing),
but like I said above I haven't seriously anaylzed it.

[anil.saldhana]

This week I have rewritten the Security Deployer (or more precisely to split into deployers based on the type of metadata). It is ready and I am checking it in tomorrow.

The classes look as follows:

public abstract class AbstractSecurityDeployer<T extends IdMetaData>
extends AbstractDeployer
{
 public AbstractSecurityDeployer()
 {
 setStage(DeploymentStages.POST_CLASSLOADER);
 ...
 setOutput(ServiceMetaData.class);
 ...
 }
}

public class EarSecurityDeployer extends AbstractSecurityDeployer<JBossAppMetaData>
{
}

public class EjbSecurityDeployer
extends AbstractSecurityDeployer<JBossMetaData>
{}

public class WarSecurityDeployer extends AbstractSecurityDeployer<JBossWebMetaData>
{ }

An issue that exists for addDependencies/addAttributes api addition to ServiceMetaData is that the internal data structures are Lists (rather than Sets) and hence there can be duplication of dependencies.

[starksm64]

In practice, this just shows that the EJB/WEB containers are not
creating their containers correctly and the respective service being
used is not exposed for IOC (or aspect dependency) properly.

If they were these kind of transitive dependencies;
ejb -> security -> security policy
ejb -> security aspect -> security policy injection into the aspect
would be would be automatic.

Creating a depends-with-optional-attribute is the equivalent ioc we supported with the mbean model. This requires adding a ServiceAttributeMetaData with a ServiceDependencyValueMetaData value. We still end up modifying the ServiceMetaData. The ServiceMetaData is an implementation detail of the ejb container as its the JBossMetaData that would have the management interface.

[adrian.brock]

An issue that exists for addDependencies/addAttributes api addition to ServiceMetaData is that the internal data structures are Lists (rather than Sets) and hence there can be duplication of dependencies.

That is to preserve the legacy semantic that it always did the
"depends optional-attribute" and attribute processing directly from the
xml file in the order listed.
There could be some stupid mbean that expects the attributes in a particular order
rather than using create to handle the multiple attribute processing, e.g.

public void setAttribute1(String one) { this.one = one }
public void setAttribute2(String two)
{
 doSomething(one, two);
}

Anyway it's not difficult for a new addDepednency() method to check
whether the list already contains the value trying to be inserted.

[adrian.brock]

Creating a depends-with-optional-attribute is the equivalent ioc we supported with the mbean model. This requires adding a ServiceAttributeMetaData with a ServiceDependencyValueMetaData value.

The "depends optional attribute" only exists in the xml, it doesn't exist
in the ServiceMetaData model, so it's not the same as the examples I listed
for the POJO stuff.

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBAS-5243 has been checked in.