-
1. Re: Modularising the appserver bootstrap
"adrian@jboss.org" wrote:
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. -
2. Re: Modularising the appserver bootstrap
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. -
3. Re: Modularising the appserver bootstrap
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 -
4. Re: Modularising the appserver bootstrap
Well don't forget that trunk is currently under a freeze. ;-)
-
-
6. Re: Modularising the appserver bootstrap
"adrian@jboss.org" wrote:
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. -
7. Re: Modularising the appserver bootstrap
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? -
8. Re: Modularising the appserver bootstrap
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.
-
9. Re: Modularising the appserver bootstrap
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). -
10. Re: Modularising the appserver bootstrap
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 -
11. Re: Modularising the appserver bootstrap
"kabir.khan@jboss.com" wrote:
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. -
12. Re: Modularising the appserver bootstrap
"adrian@jboss.org" wrote:
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)."adrian@jboss.org" wrote:
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. -
13. Re: Modularising the appserver bootstrap
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.