-
1. Re: Profile Service api
starksm64 Nov 25, 2008 10:54 AM (in response to adrian.brock)Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?
The getRootFile(DeploymentPhase) is only used to define a location that a DeploymentTemplate can use for generating a deployment. I didn't see a point to exposing multiple roots when the admin client has no knowledge of the root at all. -
2. Re: Profile Service api
adrian.brock Nov 25, 2008 10:54 AM (in response to adrian.brock)REPOSITORY API
This is a lot worse.
It's actually ok as it currently stands in princple since all of this
is actually hidden as implementation details within the
org.jboss.system.server.profileservice.repository.ProfileServiceImpl
But where this doesn't work is that some of those implementation details
have been promoted to spi when they clearly are nothing of the sort.
e.g. org.jboss.profileservice.spi.DeploymentRepository
This looks far too close to the implementation details to be done in any
other way. Even to the extent of exposing locking methods.
The AbstractAttachmentStore is probably closer to what people would
really want to use in terms of changing behaviour. But this is not spi.
But both contain incorrect assumptions like the repository and source of the
profile come from the same integration point.
These two things are seperate concerns. That should not be mixed.
My guess is that a proper seperation would make the spi(s) for these a lot simpler.
Just trying to read the source code for this is very hard.
I found it difficult to understand which parts were referring to
server/default/deploy or data/attachments/...
The assumption that server/default/deploy is a file/directory is just broken
and so are the names given to files in data/attachments (not unique enough).
I'll conclude as I started. If it were possible to implement the (sub-)profile
how you like, the current state of Repository API would not be an issue. -
3. Re: Profile Service api
adrian.brock Nov 25, 2008 11:13 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?
When I initially suggested the profile-service I imagined it as something like
(assuming a more modern maven repository)
Pseudo xml as usual :-)<profiles> <profile name="default"> <source type="Maven">http://repository.jboss.com/maven2</source> <source type="Maven">http:/repository.acme.com/maven2</source> <sub-profile>naming</sub-profile> <sub-profile>transaction</sub-profile> <sub-profile>jms</sub-profile> <sub-profile>ejb3</sub-profile> <deployment>MyApp1</deployment> </profile> </profiles>
The "deployment phase" if it is really a useful concept at all
would be included within the profile definition, e.g.<profiles name="ejb3"> <profile name="ejb3-deployer" phase="deployers"> <source type="Maven">http://repository.jboss.com/maven2</source> <deployment>jboss-jpa-deployer</deployment> <deployment>jboss-ejb-deployer</deployment> </profile> <profile name="ejb3-runtime" phase="deploy"> <source type="Maven">http://repository.jboss.com/maven2</source> <deployment>jboss-ejb3.beans</deployment> </profile> </profiles>
I say it is probably not really useful because one could assume
that the ejb3-deployer sub-profile must be fully deployed before
ejb3-runtime is deployed.
Basically, this is back to the original intention of the profile service
which is to just provide a list of deployments you want deployed
no matter where they come from.
The handling of overrides from the management console
to these original deployments is a different concern
(although you could imagine the above pseudo xml containing
xml elements that also include overrides from your own repository).
I understand there are complications if you want the original deployments
to be hot deployable (or don't if you set some lockdown flag after you've
used the management console to edit them).
The most complicated of these being patching where you try to merge
the diff of the original into the config managed by the console.
In terms of the farming (or the hot deployment prototype),
this is just another way of producing a list of original deployments. -
4. Re: Profile Service api
adrian.brock Nov 25, 2008 11:15 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
The getRootFile(DeploymentPhase) is only used to define a location that a DeploymentTemplate can use for generating a deployment. I didn't see a point to exposing multiple roots when the admin client has no knowledge of the root at all.
But shouldn't this be creating the new template deployment in the data/attachments? -
5. Re: Profile Service api
adrian.brock Nov 25, 2008 11:27 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
The handling of overrides from the management console
to these original deployments is a different concern.
This wasn't something I had in the original profile design.
In fact for a long time I assumed that JON was going to implement this
via some plugin to the profile service .
i.e. it would set the pre-determined managed objects of the deployment
(based on what has been overridden in the console and in its own repository)
before it got deployed.
The requirements then moved to be based on ManagedObjects.
After I did the initial work this, I posted that I thought the console operations should
be intercepted by the profile service using a mechanism similar to
what JBossCache does using AOP (including "transactional" change sets).
i.e. the ManagedObject/Fields would be enhanced with interceptors to trap
changes which would be persisted and progogated to the server(s).
But this was then rewritten to use ManagedDeployments and the AOP approach
got dropped. Which is where I've kind of lost sight of where this was going. :-)
I didn't expect it would end up with both the profile source(s) and console
edits in the same repository spi. :-) -
6. Re: Profile Service api
starksm64 Nov 25, 2008 11:28 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
But shouldn't this be creating the new template deployment in the data/attachments?
The issue is how different are additions going to be from the traditional deployment mechanism of placing the deployment into a deploy folder. If I add a datasource I'm expecting to see a deploy addition. Its just a question of transparency of the admin tool behaviors. -
7. Re: Profile Service api
brian.stansberry Nov 25, 2008 11:34 AM (in response to adrian.brock)You guys write way faster than I do. :)
"scott.stark@jboss.org" wrote:
Right, there is no notion of sub-profiles. How would the HASingletonDeploymentScanner be changed, deployment phases would be distinct sub-profiles that register with the ProfileService?
I don't see the contents of deploy-hasingleton as being a separate deployment phase; they are just APPLICATION, like everything in deploy.
What's special about them is their location in deploy-hasingleton marks them as belonging to a "hasingleton" subprofile. Registering them with the profile service as belonging to that subprofile could be a function of the scanner that's responsible for scanning that location. Or a function of the profile service impl; i.e. it has a configuration that understands that certain deployment URLs are associated with a particular subprofile. The latter has the advantage of allowing the regular repository HD scanner to scan both deploy and deploy-hasingleton.
Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.
The HASingletonDeploymentScanner's functionality them gets broken into 2 pieces:
1) The scanning/registration as part of subprofile function.
2) The activation function Adrian described at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136492&postdays=0&postorder=asc&start=10 . HASingletonDeploymentActivator calls profileService.deployProfile("hasingleton") when it determines it is the master node. -
8. Re: Profile Service api
adrian.brock Nov 25, 2008 11:44 AM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
"adrian@jboss.org" wrote:
But shouldn't this be creating the new template deployment in the data/attachments?
The issue is how different are additions going to be from the traditional deployment mechanism of placing the deployment into a deploy folder. If I add a datasource I'm expecting to see a deploy addition. Its just a question of transparency of the admin tool behaviors.
But then shouldn't the admin console edits modify the existing files?
How do they do if the dds are inside jars?
Ok this is simpler because it is a new file, but if the deploy/ folder is read-only
it ain't going to work. -
9. Re: Profile Service api
adrian.brock Nov 25, 2008 11:49 AM (in response to adrian.brock)"bstansberry@jboss.com" wrote:
Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.
Ok but as it stands, the profile service doesn't know about these deployments
unless the server is the singleton. Which means the console can't modify them either.
In the alternate approach the profile service/console always knows about these
deployments, its just that they may not be currently deployed if the server is not the
singleton. -
10. Re: Profile Service api
starksm64 Nov 25, 2008 11:50 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
But then shouldn't the admin console edits modify the existing files?
How do they do if the dds are inside jars?
Ok this is simpler because it is a new file, but if the deploy/ folder is read-only
it ain't going to work.
Right, its simple because its a new deployment, and its a simple component type that has a single xml fragment describing it. Generally the managed object view is a composite of multiple descriptors and its not practical to track this back to the original descriptor, if it even exists. -
11. Re: Profile Service api
brian.stansberry Nov 25, 2008 11:56 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
"bstansberry@jboss.com" wrote:
Using the scanner in that way is just a convenience for those who can't/won't add some sort of configuration a la what Adrian described above.
Ok but as it stands, the profile service doesn't know about these deployments
unless the server is the singleton. Which means the console can't modify them either.
Yes, that's the fundamental wrong thing about the current HASingletonDeploymentScanner. With the division of function into 2 parts that I described, the registration as part of subprofile function needs to happen regardless of whether the node is master. -
12. Re: Profile Service api
starksm64 Nov 25, 2008 12:17 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
This wasn't something I had in the original profile design.
In fact for a long time I assumed that JON was going to implement this
via some plugin to the profile service .
i.e. it would set the pre-determined managed objects of the deployment
(based on what has been overridden in the console and in its own repository)
before it got deployed.
That approach just was not working as the jon team could not keep up with the evolution of the server changes. We are still working through whether we have fully predetermined attachments or a delta, and both have issues.
So the repository needs another major refactoring for input into the eap. The DeploymentRepository spi was an attempt at defining the admin plugin api, but it is mixing a few things since its bootstraping from the old filesystem layout, supporting hot deployment, and admin edits. -
13. Re: Profile Service api
starksm64 Nov 25, 2008 12:23 PM (in response to adrian.brock)"bstansberry@jboss.com" wrote:
"adrian@jboss.org" wrote:
Ok but as it stands, the profile service doesn't know about these deployments
unless the server is the singleton. Which means the console can't modify them either.
Yes, that's the fundamental wrong thing about the current HASingletonDeploymentScanner. With the division of function into 2 parts that I described, the registration as part of subprofile function needs to happen regardless of whether the node is master.
Which was also the problem with the refactoring of the bootstrap; these deployments were not visible to the profile service until I updated the ProfileServiceBootstrap to expose them.
That all components are know to the profile service and can be exposed to jon needs to be a goal.