[Design of POJO Server] - Re: Profile Service api
by bstansberry＠jboss.com
You guys write way faster than I do. :)
"scott.stark(a)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=... . HASingletonDeploymentActivator calls profileService.deployProfile("hasingleton") when it determines it is the master node.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192194#4192194
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192194
15 years, 7 months
[Design of POJO Server] - Re: Profile Service api
by adrian＠jboss.org
"adrian(a)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. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192192#4192192
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192192
15 years, 7 months
[Design of POJO Server] - Re: Profile Service api
by adrian＠jboss.org
"scott.stark(a)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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192185#4192185
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192185
15 years, 7 months
[Design of POJO Server] - Re: Profile Service api
by adrian＠jboss.org
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4192175#4192175
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4192175
15 years, 7 months