[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| That's OK, but fragile. It also forces breaking things up into more fine-grained sub-profiles. It's a bit of a shame to have to do that since the MC can already properly handle the dependencies.
|
Well i don't like it - i think it's broken, because it confuses myself too, which is not a very good sign :)
I mean what we could do is to resurrect the DeploymentPhase in the xml, where you can say if it's a deployer or an application.
Maybe we can also put something there where you can say that it should ignore this profile.
That's actually the only reason behind this exercise that all the deployers are fully installed before any app is getting deployed.
Otherwise the deployment won't be recognised and nothing would happen.
I did not really get what you meant with skipping the validation on a re-entrant activateProfile :-/
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205045#4205045
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205045
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by bstansberry@jboss.com
"emuckenhuber" wrote : The original idea was to have something like:
| common/profiles/ and conf/profiles - where you could then basically say that all profiles in conf/profiles
| are getting registered. And only the root.profile gets activated (not really sure about that yet)
Perhaps this should be explicit a la ControllerMode. There's a lot of black art in what you just described.
anonymous wrote : independent profile is correct, although i'm not really happy with the DeploymentRepository stuff.
| if you e.g. look at the FilteredDeploymentRepositoryFactory - where the repository is doing the filtering. IMHO this should actually be done by the Profile itself.
I'll keep poking around, trying to prototype. I won't commit as I know you are changing stuff. But I'll give you feedback.
I was going to move farming off the list for 5.1, but won't just yet. It *really* bugs me that it's gone, and now I'm starting to see a path to getting it back.
anonymous wrote : Although this would need to be registered in the bootstrap/profile-service.xml
No problem.
anonymous wrote : But as said maybe profiles should be defined as <hot-deployment-profile/> <maven-profile/> <ha-singleton-profile/>
| or something like that ?
That seems more understandable
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205035#4205035
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205035
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by bstansberry@jboss.com
anonymous wrote : Basically all profiles need to declare their dependencies - this might get a bit redundant. Therefore implicit dependencies based on ordering.
|
| So all profiles defining deployers (maybe also mixed with some runtime beans related to it) need to be activated/deployed first. Your clustering profile would need to get deployed after this like same for a hot-deployment profile.
Yes. When I was experimenting with the XML-based profiles yesterday I divided the clustering stuff into 3 chunks -- 1) the core clustering stuff, which went earlier in the chain, 2) at the end a "clustered-deployment" profile which contained deploy-hasingleton-jboss-beans.xml and 3) the independent "deploy-hasingleton" profile for the content.
That's OK, but fragile. It also forces breaking things up into more fine-grained sub-profiles. It's a bit of a shame to have to do that since the MC can already properly handle the dependencies.
I was going to suggest going to the approach of skipping the validation on a re-entrant activateProfile call. But that has a downside too, so I'll just put down a quick pro/con for the record/my memory:
PRO: avoids need for black art in ensuring that anything that activates a profile gets put at the right point in the list of subprofiles.
CON: code that makes the reentrant call doesn't get an exception if there truly is something wrong with the nested profile. E.g. if HASingletonProfileActivator on node 1 tries to start and activate the deploy-hasingleton profile, but there's a misconfig *on node 1 only*, the HASingletonProfileActivator needs the exception so it doesn't start properly. That should then result in node 2 becoming the master and deploying the content.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205032#4205032
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205032
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| Didn't work -- the deploy-hasingleton.profile wasn't registered. ProfileServiceBootstrap only registers the 'embedded' profile and its subprofiles. Independent ones are not registered.
|
Yes this is a limitation of the current implementation/example. The original idea was to have something like:
common/profiles/ and conf/profiles - where you could then basically say that all profiles in conf/profiles
are getting registered. And only the root.profile gets activated (not really sure about that yet)
"bstansberry(a)jboss.com" wrote :
| OT, I'm starting to think about how to use an independent profile to do farming. A farmed profile would use a different DeploymentRepository impl.
|
independent profile is correct, although i'm not really happy with the DeploymentRepository stuff.
if you e.g. look at the FilteredDeploymentRepositoryFactory - where the repository is doing the filtering.
IMHO this should actually be done by the Profile itself.
Maybe the xml also needs some updating - as currently the profile is more or less defined over
it's profile-source. You can basically plugin this process by creating your own ProfileSourceMetaData.
You then would need to register this metadata over the singletonSchemaFactory (or whatever this is called)
with it's own namespace and your own DeploymentRepositoryFactory, which gets called based on the type
of the source metadata.
Although this would need to be registered in the bootstrap/profile-service.xml
That's how it's basically looks at the moment:
| <profiles
| xmlns="urn:jboss:profileservice:profiles:1.0"
| name="profiles">
| <profile name="immutable">
| <profile-source>
| <source>${jboss.server.home.url}conf</source>
| </profile-source>
| <sub-profile>ejb3</sub-profile>
| <deployment>myEjb3Deployment.ear</deployment>
| </profile>
| <profile name="mutable-source">
| <hotdeployment-source>
| <source>${jboss.server.home.url}deploy</source>
| </hotdeployment-source>
| <sub-profile>immutable</sub-profile>
| </profile>
| <profile name="maven-source">
| <maven-source xmlns="urn:jboss:profileservice:source:maven:1.0">
| <source>http://repository.jboss.org/maven2</source>
| </maven-source>
| <sub-profile>hotdeployment</sub-profile>
| <deployment>org/jboss/jboss-profileservice/6.0.0-GA/profileservice-spi.jar</deployment>
| </profile>
| </profiles>
|
But as said maybe profiles should be defined as <hot-deployment-profile/> <maven-profile/> <ha-singleton-profile/>
or something like that ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204972#4204972
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204972
17 years, 2 months
[Design of POJO Server] - Re: Sub-Profiles ProfileService changes
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| One concern with the validate is you can get unsatisfied dependencies. Say you have a war in deploy-hasingleton. And say during the 'all' profile deploy the cluster/deploy-hasingleton-jboss-beans.xml file is deployed before jboss-web.sar. That will trigger activation of the deploy-hasingleton profile, and the war will not complete deployment pending dependency on jboss-web.sar. Not a problem, since at the end of the whole thing the dependency will be satisfied and the war will deploy. Except, the validate call during the deploy-hasingleton activation will throw an exception.
Hmm yes i understand your concern - in general PS is about managing profiles it does and should
not really care about the actual type of deployments in a profile.
Which basically means that you also need corretly defined profiles :)
This leads a bit into the implicit/explicit dependcies and deployment ordering.
Basically all profiles need to declare their dependencies - this might get a bit redundant.
Therefore implicit dependencies based on ordering.
So all profiles defining deployers (maybe also mixed with some runtime beans related to it)
need to be activated/deployed first. Your clustering profile would need to get deployed after
this like same for a hot-deployment profile.
At the moment the legacy behavior of PS is still there - so deploy is activated after deployers,
and therefore your HASingleton basically activates the profile correctly.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204970#4204970
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204970
17 years, 2 months