This content has been marked as final.
Show 8 replies
-
1. Re: Configuration deployments
ccrouch Nov 24, 2008 12:11 PM (in response to dmlloyd)Hi David
I'm afraid I can't help answer your question directly, but I'd be interested to know more about your use case here. This smells like something which the profile service could/should be helping with. Could you expand on what it is you would like to achieve from the end user perspective?
Thanks -
2. Re: Configuration deployments
dmlloyd Nov 24, 2008 12:52 PM (in response to dmlloyd)From the end-user perspective, I'd like them to be able to put a foo-config.xml file in the deploy/ directory and have the container map it to a custom MetaData type for me, and then pass the resultant object into my running service.
This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC. -
3. Re: Configuration deployments
ccrouch Nov 24, 2008 1:54 PM (in response to dmlloyd)"david.lloyd@jboss.com" wrote:
This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.
Bingo. This looks like a usecase for the profileservice. So if the profileservice doesn't do what you need it to today, I think we should at least investigate what changes would be required.
- Presumably you want those runtime changes to also persist across app restarts?
- What sort of "reconfiguration" are you looking to do? Change property values?
- Would it be acceptable to annotate properties you wanted to be able to change, so the profile service knows they needed managing? Or does that count as a "hard API dependency"?
Thanks -
4. Re: Configuration deployments
dmlloyd Nov 24, 2008 2:11 PM (in response to dmlloyd)"charles.crouch@jboss.com" wrote:
Bingo. This looks like a usecase for the profileservice.
Excellent! Where can I find more information about profileservice?"charles.crouch@jboss.com" wrote:
So if the profileservice doesn't do what you need it to today, I think we should at least investigate what changes would be required.
- Presumably you want those runtime changes to also persist across app restarts?
Yes, that would seem to make sense."charles.crouch@jboss.com" wrote:
- What sort of "reconfiguration" are you looking to do? Change property values?
Perhaps a little more in depth than that - the configuration data might be somewhat complex (plain objects but also e.g. lists/sets/maps etc. as well). I'm thinking more of an object model that is mappable to an XML configuration format. I'm inclined to believe that the service itself would be in the best position to ascertain how the configuration should be merged into the running state of the service."charles.crouch@jboss.com" wrote:
- Would it be acceptable to annotate properties you wanted to be able to change, so the profile service knows they needed managing? Or does that count as a "hard API dependency"?
Annotations should be fine as long as the annotation classes are not a runtime dependency... Though I have a hard time envisioning an annotation-backed system that would be as flexible as simply plugging a metadata object into a service method when the config changes. -
5. Re: Configuration deployments
ccrouch Nov 24, 2008 3:39 PM (in response to dmlloyd)"david.lloyd@jboss.com" wrote:
Excellent! Where can I find more information about profileservice?
Here is I think the latest doco, it will give you a rough idea about what the profile service is about, but it definitely needs some updating to match the current impl.
http://www.jboss.org/community/docs/DOC-11694"david.lloyd@jboss.com" wrote:
Perhaps a little more in depth than that - the configuration data might be somewhat complex (plain objects but also e.g. lists/sets/maps etc. as well).
From that doco:
The general notion is that a deployment has a collection of ManagedObjects which are collections of detyped, self-defining properties ala the JDK6 Open MBeans notion."david.lloyd@jboss.com" wrote:
Annotations should be fine as long as the annotation classes are not a runtime dependency...
The annotations have Runtime retention but that shouldn't prevent you loading your classes in another environment that doesn't have the annotation jar file in the classpath. You're just going to need them when you compile. -
6. Re: Configuration deployments
alesj Nov 24, 2008 3:41 PM (in response to dmlloyd)"david.lloyd@jboss.com" wrote:
Is this possible to do? Maybe even using SchemaResolverDeployer to produce the custom metadata type, which is then handed to the program (perhaps with an install callback)?
Sure, this is nothing abnormal.
We do this all the time.
e.g. EJB metadata --> JBossMetaData
It eventually gets used by EJB container, helping create proper services/beans,
but never gets undeployed, since there is nothing to undeploy.
How you create your metadata is up to you.
For parsing I would definitely use SRD, as it's probably the easiest+cleanest way. -
7. Re: Configuration deployments
ccrouch Nov 24, 2008 4:02 PM (in response to dmlloyd)"alesj" wrote:
Sure, this is nothing abnormal.
We do this all the time.
e.g. EJB metadata --> JBossMetaData
It eventually gets used by EJB container, helping create proper services/beans,
but never gets undeployed, since there is nothing to undeploy.
But we don't use this technique to configure/reconfigure the EJB Container itself do we? I thought that would be analogous to what David is trying to do?"david.lloyd@jboss.com" wrote:
This would allow me to reconfigure services at runtime without having to introduce any hard API dependencies on the MC.
This sounds more like a configuration (i.e. metadata overrides, i.e. profile service issue) than a deployment shaped one.
David, if you've got the time, have you got an example of the original service deployment descriptor and an example change you would expect to see. This might help clarify if the profile service would help here or not.
Thanks -
8. Re: Configuration deployments
alesj Nov 24, 2008 4:20 PM (in response to dmlloyd)"charles.crouch@jboss.com" wrote:
But we don't use this technique to configure/reconfigure the EJB Container itself do we?
No, I would expect EJB Container to be a bunch of MC beans,
hence configurable via MC based ManagedObject."charles.crouch@jboss.com" wrote:
I thought that would be analogous to what David is trying to do?
Perhaps I didn't give the best example + missing some details. :-)
It was more about just using metadata and not making it into beans + not undeploying it.
But there is nothing preventing you to annotate your custom metadata
with ManagedObject annotations and then exposing them.
I guess some more MO impl details are needed,
e.g. InstanceClassFactory or ManagedObjectBuilder