[jboss-dev-forums] [Design of POJO Server] - Re: Sub-Profiles ProfileService changes

[emuckenhuber]

So some unordered thoughts about missing things in this prototype:

** dependencies
As mentioned before the main question for me is from where should a runtime profile know that it depends
on a deployer profile in the end? Basically we can also put the deploymentPhase in here to create the
dependencies within an xml file.

** profile-spi
Maybe we should add some properties to the Profile to define some behavior?
e.g. if the profile should do a mainDeployer.checkComplete() with an uncaught exception.
This behavior could also be implied by the deploymentPhase from the xml...

** metadata
There is an initial meta data model in the profileservice.spi.metadata.* which is basically used to create
the profile dependencies and create the deployment repositories. The <sub-profile> is then getting
a simple dependency on a profileKey. The xml could look something like this:


  | <profiles name="ejb3">
  | 	<profile name="ejb3-deployers">
  | 		<source type="immutable">${jboss.server.base.url}deployers</source>
  | 		<source type="immutable">${jboss.server.base.url}deployers2</source>
  | 		<sub-profile>metadata-deployers</sub-profile>
  | 		<deployment>ejb3.deployer</deployment>
  | 	</profile>
  | 	<profile name="ejb3-runtime">
  | 		<source type="mutable">${jboss.server.base.url}deploy</source>
  | 		<source type="immutable">${jboss.server.base.url}deploy2</source>
  | 		<deployment>ejb3-container-jboss-beans.xml</deployment>
  | 		<deployment>ejb3-interceptors-aop.xml</deployment>
  | 		<deployment>ejb3-timer-service.xml</deployment>
  | 	</profile>
  | </profiles>
  | 

I've also put a List getDependencies - for other non-profile dependencies. But not really sure if we want to have 
a profile-dependency on a service?

There is also the AbstractProfileFactory - which creates the available bootstrap profiles. I don't think this is needed in
the spi, as it should just create the bootstrap profiles, which are getting registered and actived in the ProfileServiceBootstrap.

** repository spi
Based on the xml example above, it defines 2 different types for a repository. Furthermore the filtering for the deploymentName
would also need to be done by the repository itself (see FilteredDeploymentFactory).

I'm wondering if the profile should actually do more what the repository is doing now - and the repository would become more a resource discovery.
Not sure about that, but with the current RepositoryFactory spi it's hard to share the same repository for different profiles and
to combine different repository types in a profile.
Maybe a simple method like: public DeploymentRepository createDeploymentRepository(List repositorySource); would be enough.

** VFSDeployment
Due to a comment of Adrian - should we change the VFSDeployment from the profileservice-spi to a simple Deployment ?

** ProfileService
The ProfileService uses MC to resolve the dependencies between the profiles and to install them in the correct order.
Basically all known profiles are getting registered and then you can active e.g. the "default" profile,
which will first install the other profiles this profile depends on (bootstrap and deployers). At them moment profiles
are getting registered as ON_DEMAND and started based on the dependencies. At least i think that should be 
the behavior of registering and activating a profile.
I mean we can start profiles also in a different way - but this was the easiest way to do that :)

One isssue though is that i'm using a Scoped MC controller - the only purpose of this was that if we want to do
e.g. mainDeployer.checkComplete() when installing the profiles it would fail, just because not all profiles are installed yet.
And it would also fail with "DEPLOYMENTS MISSING DEPENDENCIES" although it's a profile ;)

Furthermore when shutting down the server the ProfileServiceBootstrap is trying to deactivate all active profiles. This is not really nice,
as it is likely to happen that it tries to deactivate a profile which already has been deactivated due to it's dependencies.
Maybe we should just add a prepareShutdown() and shutdown() to the profileService?



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202223#4202223

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4202223