Modularising the appserver bootstrap

[adrian.brock]

WRT: https://jira.jboss.org/jira/browse/JBAS-5535

I never really followed up on this, but the reason why this issue has stalled
is because AOP is introducing a ciruclar dependency in the bootstrap.

AspectManager -> scoping policy -> deployment unit -> main deployer -> jmx -> aop (via @JMX)

This means we can't properly setup the bootstrap classloaders to be modular,
see the FIXMEs in conf/classloader.xml

 <classloader name="bootstrap-classloader" xmlns="urn:jboss:classloader:1.0" export-all="NON_EMPTY" import-all="true">
 <!-- FIXME Move to Deployers -->
 <root>${jboss.lib.url}/jboss-deployers-core-spi.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-core.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-client-spi.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-client.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-structure-spi.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-spi.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-impl.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-vfs-spi.jar</root>
 <root>${jboss.lib.url}/jboss-deployers-vfs.jar</root>
 <!-- System -->
 <root>${jboss.lib.url}/jboss-system.jar</root>
 <!-- FIXME Move to JMX -->
 <root>${jboss.lib.url}/jboss-j2se.jar</root>
 <root>${jboss.lib.url}/jboss-mbeans.jar</root>
 <root>${jboss.lib.url}/jboss-jmx.jar</root>
 <root>${jboss.lib.url}/jboss-system-jmx.jar</root>
 <root>${jboss.lib.url}/dom4j.jar</root>
 <!-- JAXB impl here, api is in endorsed -->
 <root>${jboss.lib.url}/jaxb-impl.jar</root>
 <!-- STAX2 impl here, api is in endorsed -->
 <root>${jboss.lib.url}/wstx.jar</root>
 </classloader>

The fix would to refactor the VFSClassLoaderScopingPolicy
such that the deployment logic is in the deployers which just invoke the
registerClassLoader()

i.e. remove its dependency on the deployment layer

That way we can bootstrap the AspectManager before the deployers and JMX
are even loaded and it becomes independent of this implementation detail.

[adrian.brock]

The fix would to refactor the VFSClassLoaderScopingPolicy
such that the deployment logic is in the deployers which just invoke the
registerClassLoader()

i.e. remove its dependency on the deployment layer

Additionally, I think the logic in this code is a bit dated?

With the new classloader, it is not just wars that can have their own isolated classloaders.
Any subdeployment with its own classloading metadata can create a sub-module
in its own classloader domain.

And even wars don't necessarily have an isolated classloader, this is just a default rule,
i.e. we add a classloading metadata to all wars that don't have an explicit one
to put them in their own classloader domain.

[adrian.brock]

I think there's also a dependency with the AspectManager bean expecting
ServiceMBeanSupport to be available.

But JMX deployment should come after AOP.

The eventual idea is to make JMX optional.

[kabirkhan]

I'll look into this ASAP, should probably be able to fix tomorrow
https://jira.jboss.org/jira/browse/JBAOP-644
https://jira.jboss.org/jira/browse/JBAOP-645

[adrian.brock]

Well don't forget that trunk is currently under a freeze. ;-)

[kabirkhan]

Ah yes, thanks for reminding me :-)

[kabirkhan]

I think there's also a dependency with the AspectManager bean expecting
ServiceMBeanSupport to be available.

But JMX deployment should come after AOP.

The eventual idea is to make JMX optional.

I am putting the original AspectManagerService code in a delegate and wrapping that in a POJO (MC/AS5) and in a class extending ServiceMBeanSupport (AS4). However, the original code contains a few methods to do with JMX from ServiceMBeanSupport such as sending out JMX notifications, getting the ObjectName of the service, getting the MBeanServer etc. Can all that stuff be left out for the MC/AS5 version? I am not really clear on how the MC beans eventually get mapped onto JMX in AS5.

[kabirkhan]

These are some of the ServiceMBean-/JBossNotificationBroadcasterSupport methods.

 public void addNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback)
 public void removeNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback) throws ListenerNotFoundException
 public void removeNotificationListener(NotificationListener listener) throws ListenerNotFoundException
 public DeploymentInfo getDeploymentInfo() throws JMException
 public MBeanNotificationInfo[] getNotificationInfo()
 public MBeanServer getServer()
 public ObjectName getServiceName()
 public int getState()
 public String getStateString()
 public void jbossInternalLifecycle(String method) throws Exception
 public void postDeregister()
 public void preDeregister() throws Exception
 public ObjectName preRegister(MBeanServer server, ObjectName name) throws Exception

The only ones I seem to be using are these:

 public void sendNotification(Notification notification)
 public long nextNotificationSequenceNumber()
 public void postRegister(Boolean registrationDone)

From the previous code it seems that things like postRegister() will get called for an MC bean in AS. But how to implement the following for an MC bean?

 public void addNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback)
 public void removeNotificationListener(NotificationListener listener, NotificationFilter filter, Object handback) throws ListenerNotFoundException
 public void removeNotificationListener(NotificationListener listener) throws ListenerNotFoundException
 public DeploymentInfo getDeploymentInfo() throws JMException
 public MBeanNotificationInfo[] getNotificationInfo()
 public MBeanServer getServer()
 public ObjectName getServiceName()
 public int getState()
 public String getStateString()
 public void jbossInternalLifecycle(String method) throws Exception

Are they required at all?

[kabirkhan]

I've looked into it properly and reminded myself how this works :-) if running in AS5, I use an MC bean, which should not care about any of the extra JMX stuff. Since we want the AspectManager to be available in JMX (mainly for the testsuite) and the @JMX stuff is not available, I register a JMX MBean in JMX, and that will bother with all the extra JMX things.

[wolfc]

The removal of the aspect deployers from a separate component is not acceptable from EJB3 embedded perspective. Embedded should have any dependency on JBoss AS or its release cycle.

Either the deployers should be put back into the CR (!) / GA release, or a new component has to be formed which allows usage by EJB3 Embedded, JBoss Embedded and possibly Web Platform (or any other).

[kabirkhan]

I see your point. Let's see what Adrian says, since it was he who originally asked me to move classpool and deployers into the AS codebase.

Reverting this would mean moving some classes back out of AS into AOP or duplicating them in AOP. Having a separate component effectively just means the same as that, with yet another dependency to manage.

The classes in question are:
org.jboss.aop.asintegration.jboss5.AspectDeployer
org.jboss.aop.asintegration.jboss5.VFSClassLoaderDomainRegistry
org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain
org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy

[adrian.brock]

I see your point. Let's see what Adrian says, since it was he who originally asked me to move classpool and deployers into the AS codebase.

Reverting this would mean moving some classes back out of AS into AOP or duplicating them in AOP. Having a separate component effectively just means the same as that, with yet another dependency to manage.

The classes in question are:
org.jboss.aop.asintegration.jboss5.AspectDeployer
org.jboss.aop.asintegration.jboss5.VFSClassLoaderDomainRegistry
org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain
org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy

So are these JBoss specific or not?

If this is appserver integration then it belongs in the appserver.

If this is some other integration, e.g. deployers-aop
then I wouldn't have a problem with them living at that level as a separate project.

As long as you are not creating a circular dependency (either really or in the
release process).

That doesn't mean the appserver has to use those specifc classes.

Ideally, these classes should be very thin anyway. i.e. the implementation
is in the aop project using agnostic policy metadata,
but the specific population of the policy choices is in the deployers.

I think you already fixed some of this already with the latest changes to
remove the deployment api dependency from the class pool.

[kabirkhan]

So are these JBoss specific or not?

They have dependencies on:
jboss-cl
jboss-deployers
jboss-vfs

So, I think the answer is "no" :-) AspectDeployer will be retired in AS when I switch to the MC based aop deployers (hopefully later this week).

I think you already fixed some of this already with the latest changes to
remove the deployment api dependency from the class pool.

Yes, second step is to get rid of the ServiceMBeanSupport dependency. I have that ready locally, but I need to do another aop release before I can add that.

[kabirkhan]

I will have a play and try to break up the asintegration module into
*asintegration-core - agnostic about the environment
*asintegration-jmx - The JMX service mbean wrapper, and the current JBoss 4 classpools etc.
*asintegration-mc - The MC service bean wrapper, and the current JBoss5 classpools etc.

Once this takes shape, I will probably also move the RepositoryClassLoader and VFSClassLoader based classpools and policies out into separate modules.

I will put in an AspectDeployer for use in JBoss embedded back as requested by Carlo, but for JBoss 5 leave the "real" deployers in AS.

[kabirkhan]

https://jira.jboss.org/jira/browse/JBAOP-652