[jboss-dev-forums] [Design of POJO Server] - Re: JBAS-5895; Processing too many classes

[scott.stark@jboss.org]

"alesj" wrote : "scott.stark at jboss.org" wrote : If someone has a custom ear libx child, but excludes the directory via metadata, then would also have to disable the include root option as well.
  |   | 
  | Why?
  | Or why is this different from if (s)he has plain lib child?
  | 
Because there is no basis to identify libx as a lib directory that was excluded. In the metadata you either specify the lib directory or an empty name to indicate there is no lib directory. If there is no directory name, its assumed to be "lib". There is no way to say exclude libx as a lib directory other than reverting to jboss structure metadata.

"alesj" wrote : 
  | The problem I see for me is that in the deployers that are Module aware
  | don't know if underlying deployment unit is top ear deployment unit,
  | since it's only structure deployers that understand ear (war, jar, ...),
  | but they don't have a clue about Module.
  | 
  | What about if I add a predetermined attachment to ear's top
  | deployment context and then grab it out in one of the deployers
  | that's just in between from Module-creating-deployer and AnnotationScanningDeployer?
  | e.g. if the attachment is there, then it means this deployment unit
  | is ear top deployment unit, hence apply root Module filter
  | Or too much of a hack? :-)
  | 
This is too much of a hack, and what I'm saying is that if someone wants an ear to include the root, but exclude non-standard lib directory, they has to use jboss specific metadata to do so. The only child location we can exclude when an empty library-directory is specific is "lib".


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

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