[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5
by kabir.khan＠jboss.com
"scott.stark(a)jboss.org" wrote :
| I have moved it to PRE_REAL. Were not converting to the generalized deployer Ales is working on in the near term.
|
Moving it to PRE_REAL does not help aop. Basically, what is happening (and to summarize and hopefully get some feedback on my approach) is:
*PARSE stage
** SchemaResolverDeployer parses the aop bean metadata from -aop.xml
** A yet to be created deployer parses the aop bean metadata from annotations using Ales's thingy.
A few further points:
- If using -aop.xml or aop annotations, an org.jboss.aop.microcontainer.beans.metadata.AOPDeployment is created. This is a subclass of AbstractKernelDeployment.
- If using a beans.xml, an AbstractKernelDeployment is created
*POST_CLASSLOADER stage
** A new deployer determines the AspectManager to be used based on classloader as before, and the aop bean metadata entries are "massaged" to reference the correct AspectManager. I also hope to be able to resolve the "duplicate interceptor entries in scoped deployments" problem I mentioned earlier in this layer.
*PRE_REAL stage
** The AnnotationMetaDataDeployer loads all the classes in the deployment looking for annotations
*REAL stage
** The AOPDeployment/AbstractKernelDeployment containing the aop bean metadata is deployed by the BeanMetaDataDeployer, resulting in the aop configuration being deployed to the AspectManager.
None of this is committed, it is all work in progress on my machine. But basically we cannot load classes until after the BeanMetaDataDeployer has deployed the aop bean metadata. As before if I get rid of AnnotationMetaDataDeployer I do get some loadtime weaving.
I have reopened http://jira.jboss.com/jira/browse/JBAS-5558 and assigned it to AS 5 CR2 since there is no way I will be able to finish this integration task by tomorrow and killing AnnotationMetaDataDeployer is a good enough workaround for me when working on this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154312#4154312
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154312
17 years, 7 months
[Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs
by alesj
"adrian(a)jboss.org" wrote :
| These tests should be using the classes in target/classes compiled from src/main
| with the deployment constructed using multiple bases.
| i.e. using the AssembledDirectory vfs
|
| Major Problems I see:
|
| 1) Use of ClassLoaderSystem.getInstance()
| Each test should be constructing its own ClassLoaderSystem not
| sharing the default one. Using the default one is bound to introduce leaks across tests.
| See for example the ClassLoaderDependenciesTest in deployers-impl
| on how to do this.
|
| 2) Isolated classloading. It should also be setting the DefaultDomain
| in its own ClassLoaderSystem to be BEFORE_BUT_JAVA_ONLY
| again see ClassLoaderDependenciesTest
| otherwise you're going to load classes from the testsuite classpath
| rather than the deployment so there's no real test at all
|
Yup, it's on my todo list.
That's been puzzling me from the beginning.
But since it worked, in both - IDEA and maven - I didn't go and investigate in details. :-)
"adrian(a)jboss.org" wrote :
| 3) BeanScanningDeployer using setRelativeOrder is a hack
| and the component handling is fundamentally broken/brain dead.
|
|
| | public BeanScanningDeployer(KernelDeploymentDeployer kdd)
| | {
| | super(AnnotationEnvironment.class);
| | setInputs(BeanMetaData.class);
| | setOutput(BeanMetaData.class);
| | if (kdd != null)
| | setRelativeOrder(kdd.getRelativeOrder() + 10);
| | else
| | setRelativeOrder(getRelativeOrder() + 10);
| | }
| |
|
| This breaks the orthogonality of the deployers. One deployer should
| not depend upon another. This needs doing in a different way.
|
| This can be seen further with the "mapComponents" stuff.
| This deployer should either be a component deployer or a top level deployer
| not mixing/matching and hacking in some bizarre way.
|
| It certainly shouldn't be creating components by delegation to a different deployer that has run earlier.
|
| Iteration and delegation, {insert explitive here :-) }
|
| | for (BeanMetaData bfb : bfBeans)
| | {
| | KernelDeploymentDeployer.addBeanComponent(unit, bfb);
| |
|
| Who knows what happens when addBeanComponent throws an error?
|
| With these current hacks it is impossible for me to insert some extra behaviour
| between these deployers because it is doing a stupid almost indeterminate dance.
| Nor can I replace one of these deployers with alternate behaviour because
| they are too tied together.
|
(A bit of cardboard posting ... again)
OK, just saw your 2nd post to this issue. :-)
"adrian(a)jboss.org" wrote :
| 4) Debugging
|
| Even if I do enableTrace("org.jboss")
| I get no inclination why this test is failing.
| Where is the debug information?
|
Coming up. ;-)
"adrian(a)jboss.org" wrote :
| 5) Others
|
| There's probably more wrong? But this is just from a basic look.
| e.g. why do these tests depend upon the VFS anyway?
|
| As far as I can tell, these tests would work just as well under the Mock classloading
| in deployers-impl if written properly?
OK, I'll leave the current one's as they are, and add a few there.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154311#4154311
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154311
17 years, 7 months
[Design the new POJO MicroContainer] - Re: Annotation Tests in deployers-vfs
by adrian＠jboss.org
My guess is that these deployers needs rewriting such the flow goes something like:
1) Deployer that collects Bean/BeanFactory annotations as attachments
2) KernelDeploymentDeployer is ammended to create components
for any Bean/BeanFactory (if metadata doesn't exist).
The association between the two deployers would be some collection
of annotations or the annotation itself with an associated factory for each.
In pseudo code:
| An abstraction that defines how to create a BeanMetaData
| from a Bean or collection of Beans (or in fact something more generic)
|
| public interface AnnotationProcessor<Class<A extends A>, Class<B extends Collection<A>>, C>
| {
| ...;
| }
|
| With a concrete implementation for BeanMetaData
|
| public class BeanProcessor implements AnnoationProcessor<Bean, Beans, BeanMetaData>
| {
| ...;
| }
|
| KernelDeploymentDeployer would take the processor(s)
| This could probably be done generically in the abstract component deployer
|
| public KernelDeploymentDeployer(List<AnnotationProcessor> processors)
| {
| setDeploymentVisitor(new KernelDeploymentVisitor());
| setComponentVisitor(new BeanMetaDataVisitor());
|
| // Add setInput for Bean/Beans, i.e. processor.getAnnotation/s()
| // Add setOutput for processor.getOutput(), i.e. BeanMetaData
| setProcessors(processors);
| }
|
The component deployer would then visit the Bean/Beans annotations
invoke run the processor then call the relevant the addComponent method
of the normal visitor.
Of course you need a way to handle duplicate names but that should be
known by the processor.
With this generic processing in place, we are back to a more reasonable flow.
* A proper depdendency between deployers
* You can easily insert between the deployers and understand what is happening
* You can replace deployers to get different behaviour
* Using a visitor pattern for the processors makes error handling easy/less error prone
* Other deployers can reuse the new metadata in an understandable way
e.g. There would be nothing to stop me writing a deployer that does
| Bean bean = AnnotationFactory.createAnnotations("@Bean ...");
| unit.addAttachment(Bean.class, bean);
|
and it would get processed naturally.
Although I don't know why you want to do this. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154305#4154305
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154305
17 years, 7 months
[Design the new POJO MicroContainer] - Re: VFS and directory handling
by alesj
"scott.stark(a)jboss.org" wrote : A nested jar should simply be seen as a JarInputStream.
|
For NoCopy handling, I can't see any other way then doing either this
| // hack the JPA url
| VirtualFile root = di.getRootFile();
| URL url = root.toURL();
| String urlString = url.toExternalForm();
| if (urlString.startsWith("vfs"))
| {
| // unpack, since that's the only way
| // to make sure we point to file
| VirtualFile file = VFSUtils.unpack(root);
| url = file.toURL();
| urlString = url.toExternalForm();
| if (urlString.startsWith("vfs"))
| url = new URL(urlString.substring(3));
| }
| pi.setPersistenceUnitRootUrl(url);
|
or like I've already said, having this check
| ZipInputStream zis;
| if (is instanceof ZipInputStream)
| zis = (ZipInputStream)is;
| else
| zis = new ZipInputStream(is);
|
Since probably if you include zis into zis, you don't get anything.
At least that's what I've encountered recently when hacking facelets resource lookup.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154297#4154297
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154297
17 years, 7 months
[Design the new POJO MicroContainer] - Annotation Tests in deployers-vfs
by adrian＠jboss.org
The annotation tests in deployers-vfs are failing for me under eclipse.
I don't know why they are working under Maven (command line)
probably a difference in classpath issue.
When I look at these tests I see a number of problems
These tests should be using the classes in target/classes compiled from src/main
with the deployment constructed using multiple bases.
i.e. using the AssembledDirectory vfs
Major Problems I see:
1) Use of ClassLoaderSystem.getInstance()
Each test should be constructing its own ClassLoaderSystem not
sharing the default one. Using the default one is bound to introduce leaks across tests.
See for example the ClassLoaderDependenciesTest in deployers-impl
on how to do this.
2) Isolated classloading. It should also be setting the DefaultDomain
in its own ClassLoaderSystem to be BEFORE_BUT_JAVA_ONLY
again see ClassLoaderDependenciesTest
otherwise you're going to load classes from the testsuite classpath
rather than the deployment so there's no real test at all
3) BeanScanningDeployer using setRelativeOrder is a hack
and the component handling is fundamentally broken/brain dead.
| public BeanScanningDeployer(KernelDeploymentDeployer kdd)
| {
| super(AnnotationEnvironment.class);
| setInputs(BeanMetaData.class);
| setOutput(BeanMetaData.class);
| if (kdd != null)
| setRelativeOrder(kdd.getRelativeOrder() + 10);
| else
| setRelativeOrder(getRelativeOrder() + 10);
| }
|
This breaks the orthogonality of the deployers. One deployer should
not depend upon another. This needs doing in a different way.
This can be seen further with the "mapComponents" stuff.
This deployer should either be a component deployer or a top level deployer
not mixing/matching and hacking in some bizarre way.
It certainly shouldn't be creating components by delegation to a different deployer
that has run earlier.
Iteration and delegation, {insert explitive here :-) }
| for (BeanMetaData bfb : bfBeans)
| {
| KernelDeploymentDeployer.addBeanComponent(unit, bfb);
|
Who knows what happens when addBeanComponent throws an error?
With these current hacks it is impossible for me to insert some extra behaviour
between these deployers because it is doing a stupid almost indeterminate dance.
Nor can I replace one of these deployers with alternate behaviour because
they are too tied together.
4) Debugging
Even if I do enableTrace("org.jboss")
I get no inclination why this test is failing.
Where is the debug information?
5) Others
There's probably more wrong? But this is just from a basic look.
e.g. why do these tests depend upon the VFS anyway?
As far as I can tell, these tests would work just as well under the Mock classloading
in deployers-impl if written properly?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154293#4154293
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154293
17 years, 7 months