-
1. Re: Deployers and classloading - stumbling block
starksm64 Sep 19, 2006 10:39 AM (in response to adrian.brock)And why can't this simply be a configuration of the deployer in the deployer-beans.xml that specifies a class loader which references the deployer URI? I do not see a need for deployers to be hot deployable as leads to bootstrap problems that are not worth the complexity in my view.
-
2. Re: Deployers and classloading - stumbling block
adrian.brock Sep 19, 2006 11:02 AM (in response to adrian.brock)That's fine as long as the deployers are playing by the rules
and are self-contained or semi-self-contained (only reference
other deployers metadata).
If they reference the runtime then you are going to leak
everything into the bootstrap classloaders.
Once one gets in there, the rest will follow like dominos.
The ideal should be to have two packages:
1) That is the deployer and its metadata, e.g. the WebDeployer
2) That is the runtime implementation e.g. web deployment and server
i.e. The deployer parses the metadata and creates a
ServiceMetaData or BeanMetaData with only string references
to the runtime classes
In practice, our implementations are a long way from this currently.
Having something that is closer to JBoss4 as an incremental step
is probably going to help us get things done faster?
I think some form of hotdeployment of deployers is going to
be done at some stage anyway.
e.g. to support people playing with profiles where the results
are more dynamic than a full reboot. :-) -
3. Re: Deployers and classloading - stumbling block
adrian.brock Sep 19, 2006 11:04 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Having something that is closer to JBoss4 as an incremental step
is probably going to help us get things done faster?
It's certainly going to get us to a working server faster
than waiting for all deployers to meet the ideal. -
4. Re: Deployers and classloading - stumbling block
starksm64 Sep 19, 2006 11:24 AM (in response to adrian.brock)But what really needs to be hotdeployable is the deployment component, not the deployers. We do need to refactor the deployers to support this. Whether or not a deployer supports hot deployment is a function of its current implementation state.
The only problem I have with statically defining deployers in the kernel bootstrap descriptor is not being able to refresh deployers. I view this as an issue with bootstrap class loader capabilities.
The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort. -
5. Re: Deployers and classloading - stumbling block
adrian.brock Sep 19, 2006 11:48 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort.
I never suggested full hotdeployment was the solution we should
implement now.
My suggestion was an intermediate stage between the bootstrap
and the deployment where the deployers are added once the
server/lib/*.jars classloader is constructed.
Where we really want to get to is hot deployment of deployers
which is an issue that I'll deal with on a different thread. -
6. Re: Deployers and classloading - stumbling block
starksm64 Sep 19, 2006 11:59 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
I never suggested full hotdeployment was the solution we should
implement now.
My suggestion was an intermediate stage between the bootstrap
and the deployment where the deployers are added once the
server/lib/*.jars classloader is constructed.
And breaking up the current bootstrap to support this is fine. I was not clear on the timeframe of the subsequent "where we want to get to..." line. We still need to restore a contract for the admin aspect of a deployment as well. -
7. Re: Deployers and classloading - stumbling block
adrian.brock Sep 20, 2006 8:06 AM (in response to adrian.brock)I've implemented this by splitting it up into three sections:
* bootstrap - conf/jboss-service.xml
* deployers - server/config/deployers
* deployments - server/config/deploy
To prove it works, I've also got hacky but working versions
of the RARDeployer and ConnectionFactory deployer in JCA.
So we now have datasources and (as a consequence) jbossmq working.
The biggest hack is deciding what should be the thread context
classloader for the bootstrap (like the old server loader did).
For now, I'm using the "first" bootstrap deployment's classloader
which is ok in this case because there is only one.
Of course when the deployers have their own classloaders
this will be a none issue. -
8. Re: Deployers and classloading - stumbling block
starksm64 Sep 20, 2006 11:37 AM (in response to adrian.brock)Ok, I have seen the current changes. What I am currently working on is validating scoped service deployments as this is needed for jboss messasging.
-
9. Re: Deployers and classloading - stumbling block
adrian.brock Sep 20, 2006 11:47 AM (in response to adrian.brock)That should already work, it is also used by the console manager:
2006-09-20 13:50:10,704 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@5364{ url=null ,addedOrder=0} 2006-09-20 13:50:10,753 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@19b2faf{ url=file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/management/console-mgr.sar/ ,addedOrder=0} 2006-09-20 13:50:10,770 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3@f800db, cl=org.jboss.mx.loading.UnifiedClassLoader3@19b2faf{ url=file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/management/console-mgr.sar/ ,addedOrder=0}