[JBoss AS Development] - JBAS-7469, move bootstrap class loading into profile
by scott.stark@jboss.org
The last piece of the legacy conf/jboss-service.xml that needs to be removed in order for the profile bootstrapURI to be dropped along with this service descriptor is the:
| <!-- Load all jars from the JBOSS_HOME/server/<config>/lib directory and
| the shared JBOSS_HOME/common/lib directory. This can be restricted to
| specific jars by specifying them in the archives attribute.
| TODO: Move this configuration elsewhere
| -->
| <classpath codebase="${jboss.server.lib.url}" archives="*"/>
| <classpath codebase="${jboss.common.lib.url}" archives="*"/>
|
I think this sould be part of the profile definition metadata and the current bootstrapURI processing replaced with the setup of a class loader bean deployment. I wanted to look more at the current bootstrap/embedded/shrinkwrap projects to what requirements exist along these lines.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266390#4266390
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266390
16 years, 4 months
[JBoss Microcontainer Development POJO Server] - Re: Getting rid of conf/jboss-service.xml
by scott.stark@jboss.org
I just commited the initial change where all services have been moved out of conf/jboss-service.xml as the smoke-tests are passing. This bootstrap descriptor is still needed for the bootstrap class loader. To completely remove conf/jboss-service.xml, the bootstrap class loader configuration also needs to be moved into the profile. JBAS-7469 is tracking this and I'll start a separate thread on that.
The services in conf/jboss-service.xml have been moved into:
deployers/core-naming-jboss-beans.xml - the basic bean and remote access bean
deploy/naming-jboss-beans.xml - legacy mbean wrapper and jndi view (which needs updating)
deploy/legacy-conf-service.xml
I think there is more work to make the naming service more usable as a mcbean such as moving the remoting piece from deployers/core-naming-jboss-beans.xml to deploy/naming-jboss-beans.xml and making better use of the remoting v3 for the remoting proxy. I'm going to look at what the requirements from the embedded usecases were before doing anything along these lines.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266387#4266387
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266387
16 years, 4 months
[JBoss AOP Development] - Re: ClassPool Refactoring
by flavia.rainone@jboss.com
Kabir has provided me feedback on this in private. He thinks that, overall, the integration is good to be ported to trunk. I'll post here the points he addressed in our private chat. These are the points that need to reviewed:
1. The field ClassPool classPool of Instrumentor should be of type AOPClassPool.
2. I should see if I can find a workaround for checks such as the one below:
if (this.childFirstLookup != delegate.childFirstLookup)
| {
| delegate.childFirstLookup = this.childFirstLookup;
| }
This check is there because childFirstLookup is a public field of ClassPool. AOPClassPool uses ClassPool as a delegate, so it can delegate to any classpool of jboss-classpool project. However, to force AOPClassPool and ClassPool to work consistently, I added these checks. This will be reviewed, but we are both afraid that maybe there is no solution for this.
3. Should ClassPoolRepository.callback be a list instead? I've made it a reference to a single callback for performance reasons. I can change it if Kabir or Ales prefer.
4. Maybe we should rename ClassLoaderRepository to avoid confusion with ClassPoolRepository class.
5.In (AOP)VFSClassLoaderDomain, instead of the initMapsDone and cleanupLoaderDone methods, I could just override initMaps() and cleanupLoader() directly in AOPVFSClassLoaderDomain, call the super method and add the "Done" stuff at the end. Kabir pointed out that this may be not so simple as it looks because I need some local variables from those methods.
I'm going to work on these points before porting the changes to trunk.
Notice that I'll have to check if the tests are still passing and do any adaptation needed on the 742 branch... This can be done only after the classpool project is estabilized and the vfs tests are passing ok. Those tests are the subject of another thread.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265325#4265325
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266376#4266376
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266376
16 years, 4 months