First, I have to say, OSGi is not silver bullet. From the classloading aspect, the most improvement is fine-grained classloading delegation, IMO. For the inverse classloading, it does not make much sense in OSGi environment, as there is no parent classloader conception in OSGi classloader arch. In the coming Geronimo 3.0-beta-1, to make those common applications work in OSGi environment, the deployer will generate a full-list import packages, which totally mimic the old Java EE's way. As mentioned by Jeff, you could use import-package to forbid loading configured classes from other bundles. e.g. <import-package>!org.apache.axis2*</import-package>, with this configuration, the deployer will not generate the import-package for those packages start with org.apache.axis2.
2011/11/2 chi runhua <[email protected]> > Inline > > Jeff C > > On Wed, Nov 2, 2011 at 7:43 PM, Radim Kolar <[email protected]> wrote: > >> > Hmm, virtual server is supported in Geronimo 3.0. >> If i remove deployement to virtual server, then applications deploys and >> starts. but not runs probably due to spring version conflict issue. >> >> java.lang.NullPointerException >> >> at org.codehaus.groovy.grails.**web.mapping.filter.** >> UrlMappingsFilter.**doFilterInternal(**UrlMappingsFilter.java:150) >> >> at org.springframework.web.**filter.OncePerRequestFilter.** >> doFilter(OncePerRequestFilter.**java:76) >> >> at org.apache.catalina.core.**ApplicationFilterChain.** >> internalDoFilter(**ApplicationFilterChain.java:**243) >> >> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(** >> ApplicationFilterChain.java:**210) >> >> at org.springframework.web.**filter.**CharacterEncodingFilter.** >> doFilterInternal(**CharacterEncodingFilter.java:**88) >> >> >> >> >> Before I checking the exception, it will be better if you could directly >>> configure the virtual host in the server.xml file in the /var/catalina >>> directory. >>> >> Actually, configuring virtual hosts should be done easily in GUI console >> like in other application servers. configuration in config.xml is kinda >> cryptic. >> >> >> > BTW, due to the timeline of the incoming 3.0-beta-1 release, I did not >> have chance to merge the root context changes to that build. not sure it >> will affect your decision. >> >> I currently could not get anything grails made to run in 3.0 due to not >> yet discovered classloading setup. I hoped that moving to OSGi will remove >> these kind of problems but it is worse because inverse classloading/non >> overitable classes combo is not supported in 3.0. >> > You may use <import-packages/> in your deployment plan for 3.0. > -- Ivan
