[Design of POJO Server] - Profile Service and Scanners
by adrian@jboss.org
This is probably two seperate questions, but I'm going to deal with them together.
Profile Service. The profile service api as it stands in terms of what is server side api
and what is client side api (or even offline api), is not good.
This really does need sorting out.
Scanners. We appear to have two implements of the scanner.
The first is the VFSScanner which is used during initial bootstrap
to scan for the deployments.
The second is the HDScanner. This asks the profile for modified deployments
on a timer.
But the profileimpl is doing its own checking for modifications.
The deployments/files it should be checking, i.e. the rules configured in
boostrap-beans.xml on the VFSXXXScanner aren't used.
So the definition of what makes up the profile is different at bootstrap time
to what it is during hotdeployment.
My recommendation would be to move all this code into the VFSScanner
and like the old scanner, we just generate "ADD" ModificationInfo
events for the bootstrap using the HDScanner to do all invocations
on the MainDeployer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064180#4064180
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064180
18 years, 8 months
[Design of POJO Server] - JBAS-4206 - ProfileService and TODOs about ClassLoader
by adrian@jboss.org
We really need to decide what we are going to do about the classloader
the deployers run under.
In the old system everything ran under the conf/jboss-service.xml
classloader which has a hook into the ULR.
In the new system, we try to emulate this, but the profile service allows multiple
bootstrap deployments so we just choose the "first one".
This is obviously very hacky.
But this isn't going to work with the OSGi style classloading.
If the deployer's deployment doesn't export its deployment classes,
the conf/jboss-service.xml classloader won't be able to see them.
You'd have the same problem if a deployer was scoped with the ULR.
What we really want is for each deployer to run under its own classloader,
i.e. the one of the deployment where is was deployed.
Assuming we do that, there's still the issue of what classloader the bootstrap
runs under.
In practice, the bootstrap classloader shouldn't be much of a problem.
It should only be in play while the main deployer (structural and normal deployers)
are determining what deployers to invoke.
So we could just run it under the real bootstrap classloader, i.e. the one
created by the ServerLoader?
I think this would just require moving things like some of the dtds and schemas
into the relevant jar, instead of them all being jboss.jar
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064174#4064174
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064174
18 years, 8 months