[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Re: Reasons for Parent-first vs. Child-first classloading

[bstansberry <nu...@jb...>]

Thanks, Scott.  Good to know about the commons-logging interaction problem; this means a static binding approach won't work in a webapp deployed on JBoss 4.0.2.  There are other cases where it won't work properly, even in webapps with child-first classloading, so I expect dynamic discovery is here to stay.

I'm curious where the type conflicts are coming from (i.e. why the container mbeans are interacting with the webapps loggers); I'll have to dig into that sometime.

anonymous wrote : Show me the spec other than the servlet spec that has any notion of class loader ordering.

None that I know of :)  Actually, a couple weeks back I looked around (a little) expecting to find parent-first specified somewhere, but found nothing.  I interpreted that as meaning containers had freedom to offer child-first classloading for all deployment types if they wanted.  I'd thought JBoss allowed that, but now realize I'd confused the meaning of the  Java2ParentDelegation flag in the deployment descriptors -- it controls whether a scoped loader will search in a parent repository for a class, not how classloading delegation works if the class is not in a repository.

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

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