[jboss-dev-forums] [Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

[adrian@jboss.org]

"scott.stark at jboss.org" wrote : 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.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130678#4130678

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130678