11:39 a.m.
I've got jboss-head (not with the latest maven stuff) booting with the latest MC
code.
The changes fall into the following categories (ignoring changes to build.xml/.classpath)
* Updates to use the classloading spi
* ClassLoaderFactory now uses DeploymentUnit rather than DeploymentContext
* ControllerMode is now an Enum rather than an interface with constants
* Removal of some hacks (and a temporary introduction of another - see below ;-)
* Removal of generics on MetaType/Value in the profile service
Here's the artifacts affected in case you are working on one of these areas:
| [ejort@warjort jboss-head]$ svn status
| M system-jmx/.classpathM
system-jmx/src/tests/org/jboss/test/system/deployers/support/CLDeployer.java
| M system-jmx/src/main/org/jboss/system/metadata/ServiceMetaDataParser.java
| M system-jmx/src/main/org/jboss/system/server/jmx/JMXKernel.java
| M system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java
| M
system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java
| M
system-jmx/src/main/org/jboss/system/microcontainer/jmx/ServiceControllerLifecycleCallback.java
| M system-jmx/build.xml
| M deployment/build.xml
| M
profileservice/src/main/org/jboss/profileservice/management/ManagementViewImpl.java
| M
profileservice/src/main/org/jboss/managed/plugins/factory/AbstractInstanceClassFactory.java
| M profileservice/build.xml
| M cluster/src/main/org/jboss/ha/jmx/HAServiceMBeanSupport.java
| M ejb3/build.xml
| M system/.classpath
| M system/src/main/org/jboss/aop/deployers/temp/Hack.java
| M
system/src/main/org/jboss/system/server/profileservice/ProfileServiceBootstrap.java
| M system/build.xml
| M
tomcat/src/main/org/jboss/web/tomcat/service/deployers/WarClassLoaderDeployer.java
| M spring-int/src/main/org/jboss/spring/deployers/SpringParserDeployer.java
| M spring-int/build.xml
| M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellDeployer.java
| M varia/src/main/org/jboss/varia/deployment/LegacyBeanShellScriptDeployer.java
| M varia/build.xml
| M j2se/.classpath
| M server/src/etc/conf/default/bootstrap-beans.xml
| M server/build.xml
| M bootstrap/.classpath
| M bootstrap/build.xml
| M messaging/build.xml
| M
webservices/src/main/org/jboss/wsf/container/jboss50/DynamicEndpointDeploymentAspect.java
| M webservices/build.xml
| M main/src/main/org/jboss/system/server/ServerLoader.java
| M embedded/src/main/java/org/jboss/embedded/ClassLoaderDeployer.java
| M embedded/.classpath
| M
testsuite/src/main/org/jboss/test/deployers/seam/test/SeamVFSClassloadingTestCase.java
| M testsuite/build.xml
| M connector/build.xml
| M build/build-distr.xml
| M build/build-thirdparty.xml
| M
aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderDomainRegistry.java
| M
aspects/src/main/org/jboss/aop/asintegration/jboss5/JBoss5ClassPoolFactory.java
| M
aspects/src/main/org/jboss/aop/asintegration/jboss5/VFSClassLoaderScopingPolicy.java
| M aspects/src/main/org/jboss/aspects/security/SecurityDomain.java
|
The work still do is what I expected (although a bit more in some parts)
WEB CLASSLOADER
The way this is currently implemented is conflicting with the infrastructure
I've put in place to do this properly.
I can get the server to boot without the WARClassLoaderDeployer stuff
but obviously there's no scoping of wars.
I'm going to work on integration the new mechanism properly next
(well after I've synched with the maven build :-)
MODULARISATION OF BOOTSTRAP
There's a number of issues here, I'll deal with this on a different thread later.
For now I've gone with the strategy of removing all the hacks and moving
some jars back into ServerLoader (i,.e. the opposite of modularisation :-).
This required the introduction of one new hack
(setting the correct parent classloader on the default domain),
| // FIXME
| ClassLoaderDomain defaultDomain = system.getDefaultDomain();
| defaultDomain.setParent(new
ClassLoaderToLoaderAdapter(getClass().getClassLoader()));
| mbeanServer.registerMBean(system, new
ObjectName("jboss.classloader:service=ClassLoaderSystem"));
|
but I can live with that until I do the modularisation properly.
AOP INTEGRATION
The temporary reversal of modularisation, i.e. moving some aop jars
into ServerLoader has resolved the @JMX issue for now.
But the major issue is that I haven't tested the changes to make
aop's as integration use the org.jboss.classloading.spi.dependency classes
rather than the old private classes from the deployers.
OTHERS
There's a couple of other minor issues I'm aware of, but these can
be easily fixed.
* @JMX is not registering the mbean with the correct classloader
so invocations on the MBean use the wrong thread context classloader
* The current way I am doing package scanning is not ignoring subdeployment
roots correctly, e.g.
/root.ear
/root.ear/sub.jar
/root.ear/sub.jar/com/acme/MyClass.class
will create a package called com.acme as expected but also one called
sub.jar.com.acme ;-)
TIDY UP
There's a fair amount of tidyup work to do as well
but the modularisation work is probably when I'll do this.
NEXT STEPS
1) Make this work with the new maven build
2) Replace the WarClassLoaderDeployer with the new subdeployment
classloader mechanism
3) Make sure AOP is still working
4) Standup tests and fix problems (like the OTHERS raised above)
5) Commit it (with fair warning first :-)
6) Do the modularisation work (to be discussed)
7) Work towards getting proper RC1/GA releases of the MC artifacts
e.g. fixing/refactoring the deployers and closing all the JIRA issues in the MC
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136382#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...