Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/546047#546047
--------------------------------------------------------------
> David Lloyd wrote:
> > Brian Stansberry wrote:
> >
> >
> > The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.
> I get where you're coming from. I'd just be concerned though if it got to a point where it is impossible to start up a server without a large and complex domain.xml file. I don't like the idea of merging XML documents though. I don't think the defaults would be coming from everyplace, just from components which are (a) managed and (b) are in use but were not specified in the domain.xml.
>
> Another scenario this could be relevant is where a component is upgraded, causing more features to become available. The component might want to update its domain configuration with the new default values for the new features. Patching a secondary XML file at upgrade time seems much messier than just using the defaults from a management perspective.
Let's get into some use cases.
1) Admin uses tool that communicates with DC to see current configuration of running domain. That means all the default values a) have to be present in the in-memory domain model so they can be displayed and b) have to be present in the in-memory domain model on the server acting as the DC.
So a) means the
components which are (a) managed and (b) are in use but were not specified in the domain.xml
must be provided with an SPI via which they can publish the defaults back to the domain model. Not the end of the world.
But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.
We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration.
2) Admin uses some other tool to access "the domain database" for a non-running domain and manipulate its configuration. This means the domain configuration needs to be in an accessible, persistent form; i.e.. I don't know if this is a real use case, but am throwing it out there just so we think about it. There is a nod toward it in some product requirements
| Instances will still be configurable even if they are not currently running. Changes will become active when the instance is next started. |
but it's not clear whether "Instances" means a Server (and not the DC) or whether it also means we can't require a DC. It's also unclear exactly what "configurable" means. If you can edit domain.xml in a text editor, the domain is configurable. I'll try and get some clarity on this requirement.
Re: the upgrade situation, that's a good general question. It does make clear the flaw in using the schema for defaults: if the user doesn't update their domain.xml to use new schema version, the new defaults are unavailable.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546047#546047]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2694 and JBPM-2798
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2694 and JBPM-2798"
To view the discussion, visit: http://community.jboss.org/message/546024#546024
--------------------------------------------------------------
> HuiSheng Xu wrote:
>
> Actually, before I saw the Martin's patch, I have just create a patch just as same as you mentioned, But I am worried if people have to configure JTA twice, both in hibernate.cfg.xml and jbpm.cfg.xml, they could make mistake. So I think Martin's patch may be better.
Yes, that is a potential risk but in fact you are configuring two different components (hibernate and jbpm) I would say that having that configuration in jbpm.cfg.xml makes it not so tightly connected to hibernate and can be better in long term.
> HuiSheng Xu wrote:
>
> About JBPM-2798, I am really not sure if this is caused by the compositeIds(), so I think we could deplay this issue and wait for somebody to clarify it.
Fine with that. Would be good if some one could give a try with latest trunk version if that is still an issue.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546024#546024]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 7 months