April 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535762#535762 -------------------------------------------------------------- > Brian Stansberry wrote: > > Requirement #2 is somewhat in conflict with some of what I've read on this thread, wherein the domain.xml configuration data is applied as an override. That means the primary and authoritative representation of the domain is the combination of wherever the overridden configuation values come from + the domain.xml configuration. > > That's always going to partially be the case, because all the IOC wiring stuff is really configuration. But how far are we looking to push this concept? I'm going to give a specific example below, but I'm less interested in the specifics than the general issue of how much is meant to be coming from domain.xml. What you mentioned about "the IOC wiring stuff is really configuration" - seem to be the one of the problems with configuration in general. Our current management view is actually a override of the original deployment metadata representing the actual beans. This requires classloading and the bean deployed, where actual management overrides update the IOC wiring (BeanMetaData). So we were talking about using a offline MO (xml) model, defining this override and how a component is exposed though the management view. In case this would still applies the question is if this concept of configuration should be externalized in general - using the same way to register against the namespace/xpath of the domain.xml Scott mentioned. Basically this seems to be more critical in terms of persistable configuration with default values, than runtime MOs just dispatching requests or exposing metrics - which should most probably just be merged into a configuration MO. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535762#535762] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535744#535744 -------------------------------------------------------------- > Scott Stark wrote: > > The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that. This is actually a tricky part. One the one hand we cannot only expose the domain.xml only, since there would be components missing - which don't have overrides. On the other hand we cannot expose the ManagedComponents based on the deployment meta data either, since it would contain the processed variables e.g. system properties - where ${jboss.server.home} might differ from one node to another. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535744#535744] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535711#535711 -------------------------------------------------------------- > Brian Stansberry wrote: > > This is something we need to discuss with the console folks. Having a separate view for updating the domain is simpler but not particularly intuitive from a UI point of view. Perhaps more intuitive for a CLI though. We need to think about a separate DomainView in general - whereas the configuration is shared across a domain and therefore the same on all nodes, this is not true for metrics and runtime statistics. It most probably would make sense to return a collection of metrics of each node, where the management clients can decide how to present this information and do the interpretation. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535711#535711] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535708#535708 -------------------------------------------------------------- I guess we also should think about the behavior for active (running) domains - so that a active domain always takes precedence over a new node joining this management domain. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535708#535708] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535706#535706 -------------------------------------------------------------- Well at least (a) (the user configuration) should be part of the domain.xml. So that all nodes in a domain not only have a consistent configuration, but also activate the same services - regardless of -c. This is why it is important that all our deployments are moved to a common repository. (b) is a bit different. The server side configuration more represent modules, which are available in a repository and shared across multiple domains. Ultimately this has to move to a domain level, where we can use a provisioning service to provide the appropriate version of the module for a domain. Where different domains might have different versions of modules. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535706#535706] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535702#535702 -------------------------------------------------------------- Yes we certainly agree on the stable api part and i was not thinking about a dynamic content model. However i think it should be possible for e.g. SOA-P and EPP to extend this model and add their own fragments - without needing a new release of profileservice or AS. Where this might be more an issue for the server side handling which should not be visible to a user nor affect the stability of the API. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535702#535702] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Messaging Development] - Problem integrating Weblogic 8.1 JMS with Jboss 5.1

by rajsoni

rajsoni [http://community.jboss.org/people/rajsoni] replied to the discussion "Problem integrating Weblogic 8.1 JMS with Jboss 5.1" To view the discussion, visit: http://community.jboss.org/message/535663#535663 -------------------------------------------------------------- Added to Wiki.... https://community.jboss.org/wiki/IntegratingWeblogic81JMSwithJboss51 https://community.jboss.org/wiki/IntegratingWeblogic81JMSwithJboss51 thanks Tim/Jai/Farhan! -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535663#535663] Start a new discussion in JBoss Messaging Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535652#535652 -------------------------------------------------------------- Requirement #2 is somewhat in conflict with some of what I've read on this thread, wherein the domain.xml configuration data is applied as an override. That means the primary and authoritative representation of the domain is the combination of wherever the overridden configuation values come from + the domain.xml configuration. That's always going to partially be the case, because all the IOC wiring stuff is really configuration. But how far are we looking to push this concept? I'm going to give a specific example below, but I'm less interested in the specifics than the general issue of how much is meant to be coming from domain.xml. For example, how does the profile configuration fit in? Referring to a) the "user configuration" stuff described at http://community.jboss.org/docs/DOC-14742 http://community.jboss.org/docs/DOC-14742 b) the "server configuration" stuff described at http://community.jboss.org/docs/DOC-14743 http://community.jboss.org/docs/DOC-14743 We could, in increasing order of verbosity: 1) Ignore the whole thing; the profile name comes from -c and the configuration is outside of domain.xml 2) Declare the profile name in domain.xml (or maybe via -c) and allow some configuration overrides (e.g. a hot-deployment scan period) 3) Include a) in domain.xml 4) Include a number of a)s in domain.xml and use -c to set which one is used 5) Include both a) and b) 6) Include a bunch of a)s and all possible b)s Options 2, 3, 4 seem reasonable. * The same kind of thing pops up with Infinispan and JGroups configs, where AS 5 provides a number of named valid configs to choose from and the services that need a cache/channel include the name to use in their own config, with a global property to set defaults. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535652#535652] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

[PicketBox Development] - JSR-160 connectors security

by ANIL SALDHANA

ANIL SALDHANA [http://community.jboss.org/people/anil.saldhana%40jboss.com] created the discussion "JSR-160 connectors security" To view the discussion, visit: http://community.jboss.org/message/535651#535651 -------------------------------------------------------------- This is a design thread that Scott Marlow (SMarlow) and I will be using to discuss the JSR-160 integration that Scott is working on. There are some security aspects to be considered in this integration based on the JSR-160 specification. Studying the JSR-160 specification, in the section III on JMX Remote Connector API: * Section 13.12 Connector Security On the server side, when the connectors are created, they are instantiated with JMXAuthenticator. ( http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/JMXAuthen... JMXAuthenticator Javadoc) If you look at the API for JMXAuthenticator, you will see that there is just one method namely: "+*Subject authenticate( Object credential )*+". As you can see, we pass in a credential and then get back an authenticated subject. The credential can be open ended. Ok, what about the username? Read below: >From the JSR-160 specification, we see that there is a concrete class called as RMIConnector. * Section 14.4 Basic Security TBD. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535651#535651] Start a new discussion in PicketBox Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/535648#535648 -------------------------------------------------------------- > Scott Stark wrote: > > By non-classified do you mean components who's type is not in the domain.xml? If that is the case then requirement 7 about the domain model *always* takes precedence over non-classified components is always true. I actually meant everything, regardless of type. I can't really think of a case where the administrator specified domain.xml would be secondary to whatever a deployment specifies. Did you have an example in mind where we would want the deployment to take precedence? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/535648#535648] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2010