-
1. Re: EAR structure mock scanning
starksm64 May 19, 2008 1:48 PM (in response to alesj)The annotations scanning happens at the post class loader level in jbossas. Where is it happening in your new work?
The annotations scanning happening at the structure phase is duplicate that cannot be reused later. It should be based on VFS/javassist usage to avoid introducing the annotations into an incorrect class loader that cannot be determined during the structure phase. -
2. Re: EAR structure mock scanning
alesj May 19, 2008 2:08 PM (in response to alesj)"scott.stark@jboss.org" wrote:
The annotations scanning happens at the post class loader level in jbossas. Where is it happening in your new work?
Pre-real.
Obviously it must be after classloading and before real, so I chose pre-real, leaving some classloader modifications for post-cl still open."scott.stark@jboss.org" wrote:
The annotations scanning happening at the structure phase is duplicate that cannot be reused later. It should be based on VFS/javassist usage to avoid introducing the annotations into an incorrect class loader that cannot be determined during the structure phase.
That's what I'm doing - VFS/javassist. ;-)
But like I said, structure phase is not the right place to do this, OSGi wise.
e.g. we want to scan for @Stateful, but java-ee.jar bundle is not yet installed - it will only be pulled in by my apps javax.ejb.* import - so in structure phase we won't be able to resolve any @Stateful annotation. -
3. Re: EAR structure mock scanning
starksm64 May 19, 2008 2:16 PM (in response to alesj)Its not true that Stateful won't be available. These standard javaee annotations will have been brought in by server deployers into a shared server level domain as these are part of the server api when configured for javaee. They are not overridable by client applications.
-
4. Re: EAR structure mock scanning
starksm64 May 19, 2008 2:59 PM (in response to alesj)So in reality for the javaee ear structure deployer, it should not matter if it used its class loader to access the annotations. Just in general a structure deployer should not be loading classes that may be application specific.
-
5. Re: EAR structure mock scanning
alesj May 19, 2008 3:16 PM (in response to alesj)"scott.stark@jboss.org" wrote:
So in reality for the javaee ear structure deployer, it should not matter if it used its class loader to access the annotations. Just in general a structure deployer should not be loading classes that may be application specific.
Yup, that's the case here.
OK, I'll try to extract my previous code - or see if it can be directly reused - to add ear scanning for javaee annotations.
Or even generic for structure deployers as well. -
6. Re: EAR structure mock scanning
alesj May 22, 2008 8:49 AM (in response to alesj)"alesj" wrote:
OK, I'll try to extract my previous code - or see if it can be directly reused - to add ear scanning for javaee annotations.
Or even generic for structure deployers as well.
Wow, this even surprised me.
The code is completely generic *already*. :-)
I just needed to change a single modifier into public - which I don't see why I didn't have it before - and all the code is there. ;-)private void scanEar(VirtualFile root, List<EarModule> modules) throws IOException { ClassLoader classLoader = getClass().getClassLoader(); GenericAnnotationResourceVisitor visitor = new GenericAnnotationResourceVisitor(classLoader); ClassFilter included = null; ClassFilter excluded = null; ResourceFilter filter = visitor.getFilter(); List<VirtualFile> children = root.getChildren(); for (VirtualFile child : children) { VFSResourceVisitor.visit(new VirtualFile[]{child}, included, excluded, classLoader, visitor, filter); AnnotationEnvironment env = visitor.getEnv(); Set<Class<?>> statelessClasses = env.classIsAnnotatedWith(Stateless.class); // logic here ... // mark module as EJB3, ... }
So, someone needs to explain me now what is the logic behind JEE annotations and how the modules are marked.
e.g. what annotations mark some type (OK, I know the EJB3 one's, but have no clue about the others) -
7. Re: EAR structure mock scanning
alesj May 23, 2008 6:16 AM (in response to alesj)"alesj" wrote:
So, someone needs to explain me now what is the logic behind JEE annotations and how the modules are marked.
e.g. what annotations mark some type (OK, I know the EJB3 one's, but have no clue about the others)
OK, I've added this mock kind of type matching.
It will do :-), since it's not really about what you return, it's about how you do it - via annotations scanning.private Integer determineType(VirtualFile archive) { ClassLoader classLoader = getClass().getClassLoader(); GenericAnnotationResourceVisitor visitor = new GenericAnnotationResourceVisitor(classLoader); ClassFilter included = null; ClassFilter excluded = null; ResourceFilter filter = org.jboss.classloading.spi.visitor.ClassFilter.INSTANCE; VFSResourceVisitor.visit(new VirtualFile[]{archive}, included, excluded, classLoader, visitor, filter); AnnotationEnvironment env = visitor.getEnv(); Integer ejbs = getType(env, Stateless.class, J2eeModuleMetaData.EJB); if (ejbs != null) { // check some conflicts - e.g. no @Servlet, ...? return ejbs; } Integer services = getType(env, Service.class, J2eeModuleMetaData.SERVICE); if (services != null) { // check some conflicts - e.g. no @Servlet, ...? return services; } Integer appc = getType(env, AppClient.class, J2eeModuleMetaData.CLIENT); if (appc != null) { // check some conflicts - e.g. no @Servlet, ...? return appc; } Integer wars = getType(env, Servlet.class, J2eeModuleMetaData.WEB); if (wars != null) return wars; return null; } private Integer getType(AnnotationEnvironment env, Class<? extends Annotation> annotation, int type) { Set<Class<?>> classes = env.classIsAnnotatedWith(annotation); return (classes != null && classes.isEmpty() == false) ? type : null; }