-
1. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
thomas.diesler Jun 21, 2007 8:18 AM (in response to wolfc)In jbossws we have a unified meta data model that is a subset of the AS meta data model. Together with that we have adapters from the AS model to the unified model. The adapters take care of the differences between AS versions.
We also have different deployers for xml based/annotation based meta data. IMHO, its not a good idea to map xml onto annotations only to be able to use the same annotation deployer (if I understand correctly)
I believe the EJB3 project should decide on it's meta data model and use container specific components that populate that meta data model. The model should be expressed in schema, which can then be reused in the context of AS schemas -
2. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
starksm64 Jun 21, 2007 5:01 PM (in response to wolfc)The metadata and object factories should be associated with the ejb3 or common AS metadata, and the deployers should be part of the AS since they are a part of the AS.
-
3. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
adrian.brock Jun 22, 2007 11:24 AM (in response to wolfc)I have some code from last year that replaces both the EJB2 and EJB3 metadata.
Haven't had time to finish it yet. But it basically replaces the EJB2 metadata
with a facade over the EJB3 data (extending the EJB3 metadata to include
all EJB2 features).
It was originally based on the EJB3 metadata from about October
but that had a number of problems so it is nowhere near exact. -
4. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
wolfc Jun 26, 2007 7:17 AM (in response to wolfc)So we'll build up a new common metadata component in projects/??/jboss-metadata which combines EJB 2 and EJB 3 metadata (and also has JavaEE metadata).
(It's weird that you had to extend EJB 3 metadata to accommodate EJB 2, because EJB 3 should be 100% backwards compatible.)
Then in trunk we build up the deployer chain: EjbAnnotationParsingDeployer -> EjbParsingDeployer -> JBossEjbParsingDeployer.
Then the component deployers should pick up the meta data and fire off new meta data for container deployers. I think the component deployer should also register virtual supply/demand dependencies, or is that in the container deployers?
EjbDeployer and Ejb3Deployer (was EJBStage2Deployer) -> Stateful3ContainerDeployer etc.
That way an EJB 3 deployment can have EJB 2.1 CMP & BMP (spec chapter 8, 9, 10 & 11).
Maybe we can do with one EjbDeployer.
To be able to use aop.xml we'll do some trickery in the container deployers. -
5. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
starksm64 Jun 26, 2007 12:36 PM (in response to wolfc)I think we should be moving to a common EjbDeployer with different reference policies controlling how the reference is handled (injected or just a jndi binding). Same for the legacy ejb interceptors vs the spec interceptors and aop interceptors. Ideally we should be able to use the new aop interceptors with ejb 2.x components with the new ejb3 container and just drop the old stuff.
I don't want to get too bogged down in supporting this unified view out of the gate for 5.0.0 though. Let's just start refactoring the ejb3 layer with that as the ultimate goal. -
6. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
bill.burke Jun 26, 2007 4:20 PM (in response to wolfc)I like the idea of having multiple component deployers like CMP/BMP. I want to be able to remove this code for tighter "lighter" distributions.
-
7. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
wolfc Jun 28, 2007 3:28 AM (in response to wolfc)Doh, a xml parsing deployer has order 2000. An annotation parsing deployer needs to run after classloader deployer (4000), so I now have the AppClientScanningDeployer at POSTPROCESS_CLASSLOADER_DEPLOYER (5000).
But this means that a chain of EjbAnnotationParsingDeployer -> EjbParsingDeployer -> JBossEjbParsingDeployer won't work. How can this be resolved? -
8. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
wolfc Jun 28, 2007 3:59 AM (in response to wolfc)http://jira.jboss.com/jira/browse/JBAS-4506
It's currently (automatically) assign to Scott, but I think Alexey should represent EJB 2, Thomas or Heiko WS and I EJB 3. -
9. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
adrian.brock Jun 28, 2007 6:15 AM (in response to wolfc)"wolfc" wrote:
(It's weird that you had to extend EJB 3 metadata to accommodate EJB 2, because EJB 3 should be 100% backwards compatible.)
When I said I extended it to add all EJB2 features, I mean those configurations
from jboss.xml that are specific to our EJB2 container NOT ejb-jar.xml :-) -
10. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
starksm64 Jun 28, 2007 10:52 AM (in response to wolfc)"wolfc" wrote:
Doh, a xml parsing deployer has order 2000. An annotation parsing deployer needs to run after classloader deployer (4000), so I now have the AppClientScanningDeployer at POSTPROCESS_CLASSLOADER_DEPLOYER (5000).
But this means that a chain of EjbAnnotationParsingDeployer -> EjbParsingDeployer -> JBossEjbParsingDeployer won't work. How can this be resolved?
Instead of simple index based ordering, deployers should be ordered based on what the consume in terms of attachment types. If we have a very aggregate attachment where only pieces are overridden by other deployers, we need a phase notion as well. This is just a relative index based ordering for the attachment type.
I don't know if the attachment type ordering is part of the refactoring Adrian has done. Its something we talked about. -
11. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
bill.burke Jun 28, 2007 3:47 PM (in response to wolfc)IIRC, can't you just programmatically define your own order? Also, an annotation parsing deployer does not necessarily need to happen after classloader deployment so long as you have access to the .class file resources. (Javaassist).
Also I don't see why it matters what order you process meta-data. Why does annotation processing have to happen first? -
12. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
alesj Jun 29, 2007 6:11 AM (in response to wolfc)"scott.stark@jboss.org" wrote:
I don't know if the attachment type ordering is part of the refactoring Adrian has done. Its something we talked about.
Yes.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181&postdays=0&postorder=asc&start=10 -
13. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
adrian.brock Jun 29, 2007 6:57 AM (in response to wolfc)"bill.burke@jboss.com" wrote:
IIRC, can't you just programmatically define your own order? Also, an annotation parsing deployer does not necessarily need to happen after classloader deployment so long as you have access to the .class file resources. (Javaassist).
Yes it does. How do you know that the related classes (e.g. the annotations
themselves) have been deployed yet?
That is something that I'm currently working on where you can have real
classloading/deployment dependencies with the new VFS based classloader.
Also, you need to know what .class files are actually in the classpath.
e.g. maybe there is a filter in what will be the new META-INF/jboss-classloader.xml<jboss-classloader> <ignore-package>com.acme.notused</ignore-package> </jboss-classloader>
-
14. Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml
wolfc Jun 29, 2007 7:45 AM (in response to wolfc)As for the order: at one point we must have a full set of meta data attached for use in the SecurityDeployer & WebServices.
Either we do parse & scan = complete or scan & parse = complete. Since xml overrides annotations my vote is for: scan then parse.